Подарки от программис'тов
Общение с ним и заказчиком выглядит как
Понятно, абидна канешна. Одному в грязи копаться неприятно. И перспективы мрачные.
предлагает вот такой странный подход
Пока все странности непонятны, но если неудобно, то видимо решение неудачное.
Но у меня даже залогинивание не работает
Я бы начал именно с этого, либо с части которая точно не требует данные пользователя.
Подозреваю там тоже что то накрутили. Небось тоже всё своё?
Ещё он почему-то называет паттерн, который использует, MVVC (Model-View-View Controller)видимо личное изобретение, не нахожу пока
Да всё понятно - контроллер обозвал контроллером представления. Не знаю, может по аналогии с MVVM. Но меня больше смутило то, что у него в контроллер передаётся объект типа BlahBlah_ViewController, который используется как модель. Вот тут уж точно что-то своё придумал. Ну или неудачно назвал. Ну он-то неудачно назвал, а я сижу и голову ломаю - "чё за херня тут происходит?", что не добавляет душевного спокойствия. ))
И перспективы мрачные.
Перспектива простая - хотя бы год продержаться, подтянуть пока немецкий-английский, написать в резюме, что работал в немецкой фирме и стек актуальный - Блейзор. По-моему, это должно улучшить мои позиции по сравнению с тем, как я мыкался год назад. Единственное, сейчас снова некоторый спад в айти намечается, так что искать работу будет сложнее.
А это правда говорят, что после джобцентра первые полгода работодателю платит за меня фактически государство? Ну типа он берёт меня к себе на работу и рисков почти не несёт, по крайней мере денежных? Поэтому, мол, легко могут взять на пробецайт и после этого срока тут же уволить так же легко?
Это был бы самый странный атрибут, для меня это никак не валидация
Ну логика такая - если есть в БД, значит правильно ввёл. Программа по сути складская, только склад навороченный - товары гуляют по разным местам, и нужно, чтобы товар был в конкретном месте в конкретное время. Это сохраняется в таблицах БД. Т.е. товар путешествует по складу, и когда приходит куда-то - это событие сохраняется в БД. И оператор на каком-нибудь месте, когда запрашивает этот товар, должен получить подтверждение, что товар в этом месте есть - он вводит в поле типа номера товара, и если в нужной таблице в этот момент есть запись на этот номер, значит валидация прошла.
А это правда говорят, что после джобцентра первые полгода работодателю платит за меня фактически государство?
Такая возможность есть, но оно должно быть соответсвенно оформлено.
Но оно больше для безнадёжных случаев: типа предпенсионный безработный водитель погрузчика.
А это правда говорят, что после джобцентра первые полгода работодателю платит за меня фактически государство?Такая возможность есть, но оно должно быть соответсвенно оформлено.
Но оно больше для безнадёжных случаев: типа предпенсионный безработный водитель погрузчика.
Я сообщил данные своего работодателя джобцентру. Договор у меня заключён с работодателем напрямую. Дальше не знаю - может, работодатель и джобцентр (т.е. государство в лице джобцентра) договорились между собой.
Это важно, т.к. по сути может объяснить, что меня взяли лишь чтобы срубить денег. И почему держат весь пробный срок (полгода). Спустя полгода видно будет - если оставят, значит либо денег от джобцентра работодатель не получил, либо я ему всё же как-то выгоден и без выплат от государства.
и если в нужной таблице в этот момент есть запись на этот номер, значит валидация прошла.никак не тянет это у меня это на валидацию жёстко привязанную к полю.
Да назвать можно как угодно - мне нужно, чтобы можно было эту логику затолкать в атрибут и приписать его к полю.
Почему не тянет? "Введённое значение должно быть в определённой таблице БД" - чем не проверка (валидация)? "Определённая таблица БД" - это может быть таблица типа "содержимое складской комнаты номер такой-то".
Как я говорил, там типа склада (ну и производство к нему) с движущимися по нему товарами. Как я понял, движение товара не хранится постоянно в оперативке, а на каждой точке маршрута сохраняется в БД. И оператор в определённой форме вводит значение и нужна проверка - есть ли товар в определённой точке. Можно проверять длину строки, можно диапазон чисел, а можно наличие в определённом месте.
Связаны в том смысле, что у любого объекта этого типа данное поле должно проверяться на наличие в таблице БД, когда пытаешься ввести это поле.
Можно не атрибут, можно функцию. Но любую логику можно поместить куда угодно. А раз у нас валидация в атрибутах - почему бы и эту проверку туда не поместить? Тем более, что эта проверка отвечает логике работы формы - если ввели что-то неправильно, то форму подтвердить нельзя. Вот и тут - если товара в нужном месте нет, то введённое поле будет неправильным, и форму нельзя будет подтвердить.
если товара в нужном месте нет, то введённое поле будет неправильным, и форму нельзя будет подтвердить.
Возможно вопрос философский, но наличие товара не должно сказываться на валидности формы.
Я хочу заказать товар, ок, я его набираю правильно, но мне поступает сообщение, что заказ невозможен. А может я захочу узнать когда этот товар поступит.
Других подробностей не знаю. В старом приложении так сделано - проверка на наличие в определённой таблице. Мне думать об их решениях не очень хочется, да и за это не платят - у них и так куча странностей и костылей, как я уже писал, так что подобные проверки-валидации меня даже не удивляют. Им надо, чтобы я старую логику повторил с новым интерфейсом и с подходами их текущего главного разработчика.
Но у меня даже залогинивание не работаетЯ бы начал именно с этого, либо с части которая точно не требует данные пользователя.
Подозреваю там тоже что то накрутили. Небось тоже всё своё?
В коде человека, который сейчас там главный (но не изначальный автор программы), полно опечаток в именах переменных и классов. Ну ладно, когда назвал с опечаткой, но использует-то тоже потом всегда с опечаткой - неужели не замечает? Ну ок, можно и с опечатками использовать - главное, чтобы она потом в именах везде повторялась. А вот сейчас встретил такое в переменной, которая потом в CSS пойдёт
expanded = "fasle"
Вобщем, не удивляюсь, что у меня его код либо не запускается, либо работает со странным поведением и кучей ошибок, выдаваемых браузером.
Ещё у их программиста зачем-то заведено перечисление со взаимоисключающими вариантами
Enabled,
Disabled, - аналогичен HTML attribute "disabled" и применяется в их программе, если нет прав доступа
Hidden, - прямо мапится на CSS visibility
Collapsed - прямо мапится на CSS visibility
Нафига делать три варианта недоступности компонента? Не проще тогда уж рисовать и не рисовать его? Т.е. если имеешь права доступа - рисуем, не имеешь - не рисуем. Зачем юзеру знать, что вот есть ещё контролы, которые ему недоступны, т.к. прав нет? Disabled-контролы же рисуются, только недоступными. По мне, disabled-атрибут применяется не для разграничения прав, а если контрол недоступен в процессе редактирования - например, неправильно что-то ввёл в форму - кнопка подтверждения недоступна. А для прав - проще вообще этот контрол не рисовать. Но у человека какая-то своя логика.
