Ну окей, сделали компонент, скрыли элементы формы, дали возможность управлять виртуальными методами контроллера;
Трабла в том, что теперь придется извращаться, когда модель поведения формы пользователем вами для него не предусмотрена.
Как скрыть кнопку, как показать галку, как сделать так чтобы когда у меня это, то там появляется то.
Посмотрите на обращения в вашу техподдержку.
Не получается серебряной пули, и рутина уйдет тогда когда пользователи компонент по своей бизнес модели совпадают с той моделью, которой вы придерживались при написании оных компонент.
не утруждайте себя, я прекрасно понимаю, про что вы в статье рассказываете (кстати, с 2006 года сижу на ваших компонентах)
мне не понравился посыл — вы аппелируете к устранению рутины, а на деле мы приобретаем пусть может быть более правильную, но тем не менее рутину.
Возьмите 10 таких непересекающихся по функционалу форм (с MVC, MVP, MVVM, MVMVVMVM и прочими low-coupling вещами) — для того, чтобы их всех запрограммировать, придется рутинно писать контроллеры, презентеры и прочую дребедень вида отражающих свойства моделей. Ключевые слова «писать» и «рутинно».
Самое смешное, что, оно будет работать и в первом, и во втором случае, но объем работ в обоих случаях примерно одинаков (я замерял). А инкапсуляцию можно устроить и в классическом варианте, при этом устранив все минусы предлагаемого вами подхода.
Довольно часто в приложениях можно встретить формы, которые предназначены для ввода или редактирования объектов с большим количеством зависимых свойств. Построение таких форм ввода вызывает «головную боль» у разработчиков: рутинная работа по размещению редакторов, написание кода инициализации, валидации, обработчиков событий…
Для редактирования этого объекта мы использовали следующий подход: все редакторы на форме будут редактировать или отображать не свойства самого объекта напрямую, а свойства некоего объекта, связанного с редактируемым.
Имхо, получили ту же самуя рутину, но немного по-другому.
а еще вы не допускаете, что существующие модули могут друг другу противоречить.
на все ваши стремления рассказать про «невероятное» можно ответить просто — займитесь делом.
Имхо, тут цель — сделать управлятор вселенной.
Атас ваще.
Пропущена запятая после Id, стало быть селектятся все идентификаторы, но колонка называется Name.
Почему-то иногда бывает весьма сложно определить такого рода косяк, особенно в сложных запросах.
П.С. Зачем offset c fetch-ем выделили?
Трабла в том, что теперь придется извращаться, когда модель поведения формы пользователем вами для него не предусмотрена.
Как скрыть кнопку, как показать галку, как сделать так чтобы когда у меня это, то там появляется то.
Посмотрите на обращения в вашу техподдержку.
Не получается серебряной пули, и рутина уйдет тогда когда пользователи компонент по своей бизнес модели совпадают с той моделью, которой вы придерживались при написании оных компонент.
а она не всегда совпадает:)
мне не понравился посыл — вы аппелируете к устранению рутины, а на деле мы приобретаем пусть может быть более правильную, но тем не менее рутину.
Возьмите 10 таких непересекающихся по функционалу форм (с MVC, MVP, MVVM, MVMVVMVM и прочими low-coupling вещами) — для того, чтобы их всех запрограммировать, придется рутинно писать контроллеры, презентеры и прочую дребедень вида отражающих свойства моделей. Ключевые слова «писать» и «рутинно».
Самое смешное, что, оно будет работать и в первом, и во втором случае, но объем работ в обоих случаях примерно одинаков (я замерял). А инкапсуляцию можно устроить и в классическом варианте, при этом устранив все минусы предлагаемого вами подхода.
Для редактирования этого объекта мы использовали следующий подход: все редакторы на форме будут редактировать или отображать не свойства самого объекта напрямую, а свойства некоего объекта, связанного с редактируемым.
Имхо, получили ту же самуя рутину, но немного по-другому.
NDA не нарушили?:)
улыбнуло:)
хожу на рукопашный бой и прочую самооборону.