Подарки от программис'тов
Нафига, чтобы прочитать свойство, нужно обратить себя к свойству, а чтобы установить его - к специальному методу?вполне объяснимо. Фокус можно установить, но невозможно снять.
a.HasFocus = false - всегда можно написать, но это недопустимо.
Ладно, согласен - иногда бывает, что нужно так сделать. Но тогда это надо в комментах писать. А у чела комментов нет, и, похоже, принципиально. Сиди и догадывайся, почему тут так сделано. Ну или выцепляй его и пиши ему письма.
Я комменты стараюсь писать, чтобы хотя бы самому не забыть, почему тут так сделал. А тут чел 6 лет уже сидит над проектом, а комментов нет. И явно в голове всю логику и причины реализации не держит.
Нафига, чтобы прочитать свойство, нужно обратить себя к свойству, а чтобы установить его - к специальному методу?
Я бы сказал, что это составной контрол. Ну например ввод времени - два едит кокса и лейбл между ними. SetFocus устанавливает фокус на конкретный едитбокс (скажем на ввод минут), а GetFocus показывает емеет ли весь контрол фокус.
Альтернатива еще может быть такой, что HasFocus призван просто сообщать о состоянии объекта. Такой прием часто используется в WPF, когда к объекту добавляются проперти IsXXX чтобы иметь булевое значение для XAML'а
Человек завёл себе в бизнес логике кастомные типы данных, типа MyInt, MyString, которые могут получать фокус, быть отформатированы внутри себя (через перегрузку их методов или установку делегатов форматирования), быть отвалидированы, хранить сообщения об ошибках, и т.д. У этих типов есть свойство значения Value, которое хранит и устанавливает конкретное значение int, string и т.д. Но использовать его нельзя (хотя геттер и сеттер у него публичные), т.к. иначе не будет проведена логика валидации, установки фокуса и т.д. А нужно для этого использовать специальные методы, в которых всё это делается. Почему не сделать этого в геттерах и сеттерах Value? Почему свойство открыто для редактирования, если его нельзя напрямую использовать? Почему не сделать его внутренним для класса или сборки, где оно применяется напрямую?
Затем ты пишешь модель представления, в которой обычные типы данных типа int и string заменены этими кастомными типами. И затем байндишь представление на эти кастомные типы данных из бизнес логики. Но напрямую забайндить нельзя - свойство Value же нельзя использовать. Поэтому в модели представления ты делаешь своё свойство Value, в геттере и сеттере которого ты вызываешь вышеупомянутые методы по установке и чтению значений. Короче, чтобы нормально работать с этими чудными кастомными типами, делаешь обёртки вокруг них (в виде моделей представления на каждый такой кастомный тип или ещё как), которые приводят их к божескому виду, который подходит для нормальных GUI фреймворков.
Вроде, сказали, что чел, который это придумал, несколько лет работал один над этим проектом. Поэтому всякие странные поведения, паттерны, отсутствие комментов, документации и прочие прелести "одиноких гениев".
В таком случае можно написать логику сеттераО том, что сеттер может иметь подобную логику, можно еще долго и нужно обсуждать.
Но runtime ошибка немного другое, чем если видишь проблему даже до компиляции кода.
Но тогда это надо в комментах писать.Не думаю, что такие очевидные вещи будет еще кто то описывать.
Это для создателя кода они очевидные, а для пользователя - нет. Я должен не просто держать в голове, что внутри у этого свойства странное поведение, отличающееся от обычного, но и как-то самостоятельно вывести такое поведение из анализа доступных членов класса. Опираясь при этом чисто на названия - ну вот есть методы и свойства со словом Focus в названии - наверное, они как-то связаны. Но подтверждения нет. Всё это вместо того, чтобы прочитать короткий тьюториал с примерами, как этот класс или его связанные свойства и методы работают. Ну или хотя бы просто комменты у метода и свойства - "установить можно так, а прочитать - так, а не так, как вы раньше могли подумать".
без паблик сеттера, но с паблик методом установки - необычное.
Мне кажется что эта связь создалась виртуально только у вас. Проперти есть проперти, функции есть функции. То что они имеют схожие имена не должно играть особой роли.
Ну и так мне кажется всё понятно: у объекта можно опросить фокус и установить фокус, забрать фокус снаружи нельзя (только изнутри). Я никак не догоняю, что здесь необычного.
Ну и так мне кажется всё понятно: у объекта можно опросить фокус и установить фокус, забрать фокус снаружи нельзя (только изнутри). Я никак не догоняю, что здесь необычного.
По определению, в фокусе может быть лишь один объект. Вы можете снаружи установить фокус, но не забрать. Но сама установка получается, что забирает фокус. Получается, фокус можно забрать и снаружи - установкой фокуса на другой элемент. В чём смысл тогда делить геттер/сеттер на геттер и метод-сеттер, играясь в разделение ответственностей, которого (разделения) нет?
Я уже не говорю о том, что объект, у которого до этого был фокус, должен как-то узнать снаружи, что фокус теперь у другого объекта, и ему нужно снять с себя фокус. Т.е. зачем-то всё усложнили, передав управление высокого уровня (установка фокуса на элементе управления в форме) на низкий уровень - на сами элементы управления. Только они теперь должны быть все связаны, чтобы знать о своих состояниях и снимать с себя фокусы. Нахрена это делать, если управлять фокусом должна сама форма, которая и должна снимать фокусы с других элементов, если фокус переместился.
Та же байда, кстати, в этом приложении с правами доступа и контролем состояния элементов управления - элемент должен сам себя проверять, есть ли у пользователя доступ к нему и какие права редактирования. Т.е. в каждом элементарном значении (и контроле, к которому это значение привязано) хранится эта информация, и контрол сам себе меняет состояние. Я вот только не пойму, как сделать ИЗНУТРИ КОНТРОЛА, чтобы он не показывался, если у пользователя нет доступа к нему? Если бы сама форма решала - тут просто - не рисуешь этот контрол и всё. А тут вот есть HTML элемент <input>, и ты либо не рисуешь его, либо используешь его атрибут disabled. Но всё это делается на уровне формы, а не внутри самого элемента. Получается, нужно делать кастомный input, где всю разметку запихать в условный оператор - типа if (hasAccess). Абсолютно идиотское и костыльное решение.
Абсолютно идиотское и костыльное решение.
На ровном месте нагромоздили своих базовых типов. Из-за этого надо делать свои контролы на каждый базовый тип (текстбоксы для разных типов данных, лейблы, чекбоксы, списки, таблицы и т.п.). Из-за этого ни один встроенный контрол ни из одного GUI-фреймворка не подходит. Из-за этого не подходит ни одна из моделей валидации форм в этих фреймворках... Там ещё и ORM свой - костыльный и обрезанный, под которым крутится первая версия NHibernate - убогая до невозможности.
Как же достали эти "кулибины", не соблюдающие никаких правил. Как они вообще умудряются писать такой кривой софт для больших контор и не получать по шапке за свой саботаж? Читаешь, читаешь всякие советы по "чистому коду", а в реале забронзовевшие семизнаки творят всякую херню, и им за это ничего нет - наоборот, как сыр в масле катаются. Все эти "книжонки с советами" - такое ощущение, что от чуваков, которые в реальный мир не выходят, а обитают исключительно в параллельной реальности, где всё делается по написанному ими фен-шую.
Получается, фокус можно забрать и снаружи - установкой фокуса на другой элемент
За одним маленьким исключением, что имеется спец. логика для этого. Может быть еще нужно данные обновить если фокус ушел другому элементу
Только они теперь должны быть все связаны
Они только должны знать своего родителя.
Нахрена это делать, если управлять фокусом должна сама форма
необязательно. Или делать базовую форму или делать базовые элементы. В данном случае, выбрали решение делать базовые элементы.
И судя по описаниям, сильно перестарались в этом, дав элементам сильно много ответственности.
Я вот только не пойму, как сделать ИЗНУТРИ КОНТРОЛА
Не знаю конкретики, но обычно есть метод для отрисовки в базов классе, вот его и не вызывать.
По идее, все сводилось к тому, чтобы иметь максимально простые формы.
А вот формы-то как раз и не простые - в них тоже полно логики. Поэтому я и не понимаю, нафига передавать управление из формы в контролы лишь частично.
По сути, я вижу лишь одну главную ошибку, которая привела к этого дикому костылению - он придумал свои базовые типы и напихал туда бизнес-логику. После этого пошли множится костыли по цепочке: нужны свои контролы (тег-хелперы в MVC), нужны свои механизмы валидации и отображения ошибок (включая ручное применение стилей для этого - типа красных рабок вокруг контрола и прочих "эффектов"), нужны свои средства коммуникации между этими god-object-custom-basic-types. Надо было сделать всё на моделях, на которые ложится вся встроенная валидация, формы и прочее во всех нормальных фреймворках. Нет, он пошёл поперёк всех. Он обмолвился, что мол нужна кастомная валидация - типа проверить значение в БД. А что, свой атрибут валидации не может проверить значение в БД?
Ещё он почему-то называет паттерн, который использует, MVVC (Model-View-View Controller), а не MVC. И модель называет View Controller. Т.е. я вижу, что у него есть класс Чего-то_там_ViewController, который он натурально использует как модель в MVC-фреймворке. Я ещё первое время путался в названиях его классах и понять не мог - где модель-то?.. Т.е. модель у него тоже всё таки есть, но она состоит из кастомных базовых типов. И логика сидит частично в модели, частично в его типах.
А вот формы-то как раз и не простые - в них тоже полно логики
Тогда немного странно
Он обмолвился, что мол нужна кастомная валидация
так что оригинальный разработчик под боком?
свой атрибут валидации не может проверить значение в БД
Каким образом? Данные и база в роде в разных местах. Или что под этим понималось?
Ещё он почему-то называет паттерн, который использует, MVVC (Model-View-View Controller)
видимо личное изобретение, не нахожу пока 
так что оригинальный разработчик под боком?
Как мне сказали, сначала софт был написан одной фирмой, затем его купила другая крупная фирма, которая ещё через какое-то время наняла стороннего человека для переписывания этого софта. Ну и вот теперь они хотят ещё одного (это я), который им (пока что) лишь гуй перепишет но новый фреймворк. Похоже, меня наняли потому, что с предыдущим челом у них что-то долго не получается (первые коммиты в репу от него я видел с датами лет шесть назад). Они ещё сказали, что у них был опыт с другими в помощи по переписыванию - неудачный.
Оригинальные разрабы, похоже, давно ушли. Связи с ними нет. А тот человек, что сейчас и уже давно переписывает, предлагает вот такой странный подход. При этом у него самого на его фреймворке почти ни одной работающей формы нет - там что-то по залогиниванию и какие-то наработки по основным формам, работающим с бизнес-логикой. Но у меня даже залогинивание не работает. Т.е. демонстрационного доказательства, что его подход работает и как, тоже нет. Вдобавок, он ещё и не пишет комменты к своему коду (почему и как что-то работает, зачем нужно). Лишь на словах поясняет и недавно я попросил типа инструкции написать. Общение с ним и заказчиком выглядит как череда писем и видеоконференций, где я по крупицам вытаскиваю подробности (с учётом некоторого недопонимания из-за моего корявого немецкого), из которых часто узнаю, что я не могу нормально использовать ту или иную удобную и очевидную штуку из Блейзор-фреймворка, т.к. у него там другой подход. Что, конечно, не добавляет энтузиазма.
свой атрибут валидации не может проверить значение в БДКаким образом? Данные и база в роде в разных местах. Или что под этим понималось?
Насколько я помню конкретные места, там юзер вводит обозначение объекта (что-то типа айди) в текстовое поле вручную, и валидация заключается в проверке, есть ли такой объект в БД. Если есть - открываем для редактирования следующие контролы формы, переводим фокус на один из этих контролов. Не вижу причин, почему это нельзя встроить в стандартную модель валидации через атрибуты. В атрибуте указать... да ничего не надо указывать - данные для соединения с БД и реквизиты текущего пользователя и так можно брать из приложения. Текущее значение поля берёшь и проверяешь, есть ли это значение в БД. И назвать атрибут как-то типа "ExistsInDatabase".