И еще

[metaclass]

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

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

Comments

[metaclass.livejournal.com]

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

[g-rub.livejournal.com]

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

[1ceheart.livejournal.com]

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

[metaclass.livejournal.com]

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

[g-rub.livejournal.com]

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

:)

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

И готово.

[metaclass.livejournal.com]

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

[g-rub.livejournal.com]

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

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

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

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

[g-rub.livejournal.com]

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

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