Есть ли будущее у DELPHI?

--Ins-- зачем вам вин формы? впф юзайте.

Цитата DesweR @ 28.03.12, 08:00

Да, тот который мы изменяем (Edit2).

Отлично, смешали View и Model, в духе Делфи, чо.

DesweR, MVC вообще нет ни в каком виде в Delphi?

Цитата DesweR @ 28.03.12, 08:00

Кажется начинаю понимать (почитал ещё статью на хабре), в LiveBindings система связи с точностью до наоборот. Опиши поподробнее, как будет выглядеть процесс связывания двух Edit'ов и Label'а (из той задачки), а потом и свою задачку подгоню.

Ну все просто, у контроллера будет Outlet типа TextField, а на интерфейсе например два UITextField, и они просто мышкой связываются с этим Outlet'ом. Всё.

Цитата D_KEY @ 28.03.12, 08:49

DesweR, MVC вообще нет ни в каком виде в Delphi?

А ты последние страницы читал?

Цитата DesweR @ 28.03.12, 08:00

Хэх, так что реализацию самих Action'ов нужно самому писать всё-таки?

В каком смысле "реализацию Action'ов"? Если ты про класс Action, то нет, пишется "обработчик Action.Execute" и всё. Соответственно можно просто связать два элемента интерфейса, если у них есть какое-то взаимодействие, не связанное с контроллером/моделью, т.е. чисто UI-шное взаимодействие.

Цитата --Ins-- @ 28.03.12, 08:51

Цитата D_KEY @ 28.03.12, 08:49

DesweR, MVC вообще нет ни в каком виде в Delphi?

А ты последние страницы читал?

По диагонали. Меня GUI сейчас мало интересует.
Впечатление об отсутствии MVC создалось по критике со стороны korvin'а

Цитата D_KEY @ 28.03.12, 08:54

По диагонали. Меня GUI сейчас мало интересует.
Впечатление об отсутствии MVC создалось по критике со стороны korvin'а

Отчасти да:

• с моделями в VCL туговато, есть только TDataSet и его потомки по большому счету.
• в качестве контроллера можно использовать TActionList.
• с вьюхами тоже как-то вяло (TDB*-классы).

Плюс реализация обработки событий для компонентов описывается в коде класса-контейнера (например SomeButton.OnClick в классе формы, на которой эта кнопка расположена) а не в коде самого компонента, что приводит к смешению обязанностей и следовательно несоблюдению MVC.

Но в принципе писать в стиле MVC вполне можно.

korvin, в VCL класс формы, юнит формы сам выполняет роль контроллера для собственных визуальных элементов - обработать ввод и передать модели, или наоборот - сингал от модели - вывод в элементы управления. ИМХО - ничего плохого в этом нет. Бывает что у некоторых он еще и моделью является, но это уже говнокод.

Сообщение отредактировано: --Ins-- - 28.03.12, 14:14

--Ins--, т.е. контроллер всегда совмещен с представлением?

Цитата D_KEY @ 28.03.12, 14:14

--Ins--, т.е. контроллер всегда совмещен с представлением?

Почему всегда? Не всегда, я например эту функцию как правило перекладываю на отдельную сущность. Но зачастую - форма представляет собой и вид, и контроллер, т.к. группирует все компоненты, управляет ими - ну сам бог велел. А какой еще код в классе формы писать, если не код контроллера?

Сообщение отредактировано: --Ins-- - 28.03.12, 14:19

Цитата --Ins-- @ 28.03.12, 14:13

korvin, в VCL класс формы, юнит формы сам выполняет роль контроллера для собственных визуальных элементов - обработать ввод и передать модели, или наоборот - сингал от модели - вывод в элементы управления. ИМХО - ничего плохого в этом нет. Бывает что у некоторых он еще и моделью является, но это уже говнокод.

Плохое в этом есть: контроллер засорен кучей ненужных ему визуальных компонентов (панели, статичные лейблы и т.п.) и, как сказал D_KEY, совмещен с представлением, а следовательно имеем меньше гибкости и смешивание кода разных сфер ответственности, т.е. лапшекод.

Добавлено 28.03.12, 14:22

Цитата --Ins-- @ 28.03.12, 14:17

Почему всегда? Не всегда, я например эту функцию как правило перекладываю на отдельную сущность. Но зачастую - форма представляет собой и вид, и контроллер, т.к. группирует все компоненты, управляет ими - ну сам бог велел. А какой еще код в классе формы писать, если не код контроллера?

А зачем вообще код в классе формы писать? Максиму код поведения самой формы как визуального элемента (отрисовка и т.п.).

Сообщение отредактировано: korvin - 28.03.12, 14:23

Цитата korvin @ 28.03.12, 14:20

Плохое в этом есть: контроллер засорен кучей ненужных ему визуальных компонентов (панели, статичные лейблы и т.п.)

Это ж тебе не c#, здесь код создания компонентов не генерируется, компоненты из ресурсов загружаются. Так что никакого засорения нет, кроме объявления полей для каждого компонента - но эти поля нужны контроллеру - а как иначе обращаться к элементам? Так что тут я с тобой не согласен

Цитата korvin @ 28.03.12, 14:20

а следовательно имеем меньше гибкости и смешивание кода разных сфер ответственности, т.е. лапшекод.

Меньше гибкости - возможно, любой промежуточный уровень абстракции добавляет гибкости, но как говорится, все проблемы проектирования можно решить путем введения нового уровня абстракции кроме проблемы слишком большого числа уровней абстракций В общем, иногда эта твоя гибкость для простых случаев форм никому не нужна и нефиг городить огород. А смешения уровня ответственности, как я указал выше, не наблюдаю - считаю что форма (не окно формы на экране, а КЛАСС формы - как сущность в коде) вполне ответственна за управление своими элементами

Добавлено 28.03.12, 14:27

Цитата korvin @ 28.03.12, 14:20

А зачем вообще код в классе формы писать?

Вот собственно за этим Ни для чего другого - незачем. Класс формы с классами-компонентами связан отношением агрегирования. Ты когда пишешь некий класс-агрегат, ты же его клиентам не в виде набора запчастей предоставляешь, а в виде целостного, где внутри внешний класс управляет внутренними. Вот и здесь так же

Сообщение отредактировано: --Ins-- - 28.03.12, 14:41

Цитата --Ins-- @ 28.03.12, 14:26

Это ж тебе не c#, здесь код создания компонентов не генерируется, компоненты из ресурсов загружаются. Так что никакого засорения нет, кроме объявления полей для каждого компонента - но эти поля нужны контроллеру - а как иначе обращаться к элементам? Так что тут я с тобой не согласен

А зачем мне в контроллере обращаться к куче панелей, которые только и нужны для создания раскладки и статическим лейблам? В крайнем случае для нужных можно сделать и Outlet'ы.

Вот в IDEA можно связать с полями только те элементы интерфейса, с которыми необходимо работать, а все остальные не связывать, поэтому там класс формы значительно менее захламлен.

Добавлено 28.03.12, 16:21

Цитата --Ins-- @ 28.03.12, 14:26

Меньше гибкости - возможно, любой промежуточный уровень абстракции добавляет гибкости, но как говорится, все проблемы проектирования можно решить путем введения нового уровня абстракции кроме проблемы слишком большого числа уровней абстракций В общем, иногда эта твоя гибкость для простых случаев форм никому не нужна и нефиг городить огород. А смешения уровня ответственности, как я указал выше, не наблюдаю - считаю что форма (не окно формы на экране, а КЛАСС формы - как сущность в коде) вполне ответственна за управление своими элементами

О да, MVC -- это такой большой набор абстракций, аж жуть.

Добавлено 28.03.12, 16:23

Цитата --Ins-- @ 28.03.12, 14:26

Вот собственно за этим Ни для чего другого - незачем. Класс формы с классами-компонентами связан отношением агрегирования. Ты когда пишешь некий класс-агрегат, ты же его клиентам не в виде набора запчастей предоставляешь, а в виде целостного, где внутри внешний класс управляет внутренними. Вот и здесь так же

Дык а нафиг тогда в классе формы описывать поведение других компонентов (Лейблов, едитов, баттонов и т.д.)? Зачем вообще эта нелепая возможность?

Сообщение отредактировано: korvin - 28.03.12, 16:23

Цитата korvin @ 28.03.12, 03:51

Цитата [S]mike @ 27.03.12, 20:20

А все равно приходится. У меня в дельфях, например, есть свой фреймворк-обертка над TAction

Можешь чуть подробней описать, что он добавляет к TAction'ам?

Ну вот например есть общий (не путать с абстрактным) класс TListCtrl, служащий для табличного отображения данных. Он по сути является контроллером, позволяет подменять свою имплементацию (ListView, VirtualTreeView). И он реализует набор стандартных действий с помощью TAction. Отличие от дельфийского подхода в том, что компонент генерируется в рантайме, а экшены просто присваиваются обработчикам. Есть еще всякие методы для динамической генерации экшенов. Просто со временем понимаешь, что сложно проектировать сложные, но в то же время гибкие приложения, используя обычный дельфи-вей: накидал компонентов, прописал обработчики. Скорее гуй должен служить легкой оболочкой для связывания уже имеющегося функционала - вот чему посвящена моя библиотека (я ее называю RCL - Runtime Components Library). В то время как VCL только запутывает функционал. В этом, имхо, и одна из основных проблем дельфей - гуй получается первичен, вот многие и концентрируют функционал внутри одного модуля, в котором потом ногу сломишь.

Хотя я ни в коем случае не противник визуального построения форм (а в дельфях встречаются и такие фанаты ).

Вот например как у меня выглядит код:

  FList := CreateListControl(Self, DataEvent, nil,
    [ColumnRec(rsExpression, 350),
     ColumnRec(rsResult, 100, 150, 80)]);
  FList.PopupMenu := CreatePopupMenu(FList, [
    FList.GetDefaultAction(FActionList, ListUse, rsUse),
    nil,
    FList.GetDeleteAction(FActionList, ListDelete),
    FList.GetClearAction(FActionList, ListDelete)
  ], 0);
  FList.MultiSelect := True;

Все стандартно, удобно, единообразно и очень гибко.

Добавлено 28.03.12, 18:00

Цитата --Ins-- @ 28.03.12, 14:26

Это ж тебе не c#, здесь код создания компонентов не генерируется, компоненты из ресурсов загружаются. Так что никакого засорения нет, кроме объявления полей для каждого компонента - но эти поля нужны контроллеру - а как иначе обращаться к элементам? Так что тут я с тобой не согласен

Ну начнем с того, что все компоненты на форме захламляют класс формы. Во-вторых, они все в published-секции, то есть нарушаются основные догмы ООП.

Цитата korvin @ 28.03.12, 16:19

А зачем мне в контроллере обращаться к куче панелей, которые только и нужны для создания раскладки и статическим лейблам? В крайнем случае для нужных можно сделать и Outlet'ы.

Справедливости ради хочу сказать. Если в Object Inspector стереть Name компонента, то для него не будет генерироваться объект в классе формы.

НО!
1) Эта возможность весьма неявная, не знаю даже, написано ли об этом в хелпе.
2) Как и все в дельфях - иногда глючит.
3) Нельзя делать связи между компонентами, так как компонент теряет свое имя. Вот представим ситуацию: есть компонент PopupMenu, который не используется в коде. Но присвоить его какому-то компоненту на форме будет нельзя! Придется "терпеть" его в коде формы.
4) Нужно в initialization прописывать в RegisterClasses те компоненты, которые лежат на форме, но не имеют имен (так как их функционал иначе будет исключен линкером).

Добавлено 28.03.12, 18:13

Цитата korvin @ 26.03.12, 18:48

С другой стороны Xcode/InterfaceBuilder прекрасно парсит описания классов Objective C и позволяет работать с ними средствами гуя без всяких RegisterComponents, спецификатора published, наследования от TComponent(хз, может и не обязательно, но я так понимаю, что без наследованиия придется много ручками поработать?) и прочих костылейспециальных вещей в отличие от всей такой компонентно-ориентированной делфи =)

Согласен. Библиотека компонентов в целом в Delphi крайне не продумано. Тебя принуждают иметь зоопарк. Нельзя в одном проекте использовать одни компоненты, а в другом другие. И самое худшее - нельзя в проекте использовать СВОИ компоненты. Нужно делать пакет, который ставить вместе со всеми остальными. И потом искать свои компоненты среди 1000 других. Ужас!