И еще

[metaclass]

Писать GUI на хаскеле - это все равно, что писать GUI на SQL.

Если обернуть фразу - то для того, чтобы сделать нормальный GUI фреймворк для хаскеля (а не сплошную имитацию императивщины на монадах), нужно представить GUI в декларативно-функционально-теоретико-множественном стиле :)

Comments

[jtootf.livejournal.com]

Phooey (http://darcs.haskell.org/packages/phooey/doc/html/Graphics-UI-Phooey-Applicative.html), Fudgets (http://www.cs.chalmers.se/ComputingScience/Research/Functional/Fudgets/springschool95-intro.html)

вполне себе функционально. кстати, а где в описании GUI нужна императивщина?

[sergiej.livejournal.com]

Я видел веб гую генерируемую полностью из Pl/SQL. И ничего. Конечно сама она была HTML

[aamonster.livejournal.com]

Вот я пишу на императивщине, и все мне кажется, что изрядная часть гуя должна быть декларативной. Как минимум - лэйауты, enable/disable кнопок и т.п.

[metaclass.livejournal.com]

Я такое делал, после чего оказалось, что в таблицу состояний UI приходится подключать большие куски кода на императивном языке(через подгрузку классов по их имени) и это все становится неподдерживаемым и неотлаживаемым.

[metaclass.livejournal.com]

Видел я скриншоты GUI на этом. За такое с работы увольняют.
Но вообще идея насчет комбинирования GUI из элементов сама по себе правильная.

А императивщина нужна, когда GUI сильно динамический, т.е. юзер ткнул в один элемент - десять других поменяли свое состояние. Я делал декларативное описание такого на XML - этот продукт в процессе разработки потерял поддерживаемость года где-то за два, сейчас буду переделывать и переносить декларативные описания внутрь кода(структура примерно такая же, но в качестве описания будет структура .NET класса, управляющего GUI, а всякие проверки и прочее - чисто императивный код).

[g-rub.livejournal.com]

Если посмотреть в разрезе парадигмы MVC, то логика грамотно спроектированного View (отрисовывающего себя сообразно состоянию модели) -- целиком и полностью функциональна.

Что касается контроллеров -- вся логика валидации действий тоже как правило целиком функциональна. Единственная императивщина -- собственно дергание модели запросом на изменение состояния.

Все жесткие правила относительно последовательных цепочек действий -- разруливаем, реализовав на уровне модели объект "сессия" и сведя задачу к предыдущей.

Вот и выбросили из ГУИ 99% императивщины, которой там при правильном проектировании изначально не должно было быть.

[jtootf.livejournal.com]

это не императивщина, это уже event-driven. а как раз в event-driven функциональщина чувствует себя очень неплохо - можно смотреть FRP, работы Элиотта, YAMPA (AFRP)

ну а что GUI страшное, так речь не о том; это - интерфейс, снизу к нему хоть Qt пристегнуть можно, хоть GTK# (насчёт WinForms не уверен)

[metaclass.livejournal.com]

Да, так обычно и делается, только вот накладываемые ограничения приводят к тому что "мыши плакали, кололись, но продолжали жрать кактус".
Зависимости внутри GUI между элементами проще выражать в виде обычного императивного кода "выбрали строку в гриде->кнопки стали разрешены", а не в виде "Выбрали строку в гриде - событие ушло в адаптер грид-источник данных -> адаптер поменял модель -> пошло событие "модель изменена" на view -> view перерисовалось". При этом еще желательно что бы изменялись только кнопки, а не весь view целиком, т.е. нужно на каждое изменяемое свойство отдельное событие, и все это писать руками никакой радости нет.

[metaclass.livejournal.com]

Да, FRP, видимо, должно подойти. Промоделировать юзера как две сущности - одна генератор событий, а вторая - функция, преобразующая вывод программы в вводимые данные :)

[g-rub.livejournal.com]

Давненько уже гуйню не писал, но что-то мне кажется что явным образом включать-выключать кнопки меню из обработчика табличного поля -- прямая дорога в ад.

[1ceheart.livejournal.com]

+1, но умение перерисовывать часть модели (и соответственно, знание того, какая часть была изменена) часто довольно важно, даже в вебморде, иначе никакого сервера не хватит. А если я 3D-чертеж на экране отображаю, то "перерисовать view" - это может вечность занять. Жизнь все-таки сложнее голых схем, но глобально, конечно, енаблить кнопку по нажатию другой кнопки не сильно кошерно :)

[metaclass.livejournal.com]

Я думал после того, как сделаю общую функциональность, оптимизировать это дело методом вычисления диффа между объектами, потом по этому диффу вычислить дифф для view объекта.
Но как всегда, сначала на это дело не хватило времени, а потом проект законсервировался, т.к. тендер выиграла другая контора :)

[metaclass.livejournal.com]

Да, так и есть.
Альтернатива дороге в ад - отладка вызовов функций 20-уровневой вложенности - от кнопки до модели и обратно до view :)

[g-rub.livejournal.com]

Ну как бы "сказать части view перерисовать себя" и "из напрямую из контроллера модифицировать отображение" -- две ооочень большие разницы.

:)

Потом другой контроллер модифицирует то же отображение по-своему, и дальше начнется, потом третий контроллер попробует эту кнопку "восстановить в исходную позицию" сообразно своей логике...

И готово.

[g-rub.livejournal.com]

Хранить логическое состояние хотя бы в соответствующих переменных-атрибутах формы не судьба?

И включать-выключать кнопки по итогам чтения этого состояния, а не по воле контроллера?

А обмен сигналами об изменении -- через простенький диспетчер, решающий кому надо перерисовываться по итогам изменения набора переменных?

Не вижу что-то тут 20 уровней вложенности.
Банальное отделение логики от представления.

[g-rub.livejournal.com]

В MVC не 20 уровней, а 3.
Соответственно, направлений взаимодействия -- никак не может быть больше 6 (а реально -- 3-5).

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