Previous Entry Share Next Entry
photo24

Как делать хороший GUI и data bindings (Почти серебряная пуля, да)

Оригинал взят у justy_tylor в Как делать хороший GUI и data bindings
Сначала хотел прокомментировать в http://jakobz.livejournal.com/238313.html , но решил подробнее осветить тему в виде отдельного поста.

Итак, как делается хороший динамический GUI при большом количестве данных:

I. Забудьте MVC. Это доисторический хак из тех времён, когда пещерные оопэшники с удивлением обнаружили, что вьюх может быть больше одной и стали придумывать костыли для реализации. Но ведь бывают не только вьюхи.

В каждый отдельный момент времени в типичном приложении могут быть активны:
1. Настройки приложения, включая типовой background_color для текста.
2. Множество окон, использующих в реальном времени эти настройки.
3. Диалог выбора цвета, в котором в данный момент редактируется настройка background_color.
4. Датасет локализации, из которого подкачиваются тексты для интерфейса приложения, включая метки в диалоге.
И это лишь одно из сочетаний.

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

II. Забудьте FRP. Это непредсказуемая помойка невидимых состояний "на проводах". А зачем плодить дополнительные невидимые состояния, если нам надо всего лишь соединить видимые (например, между диалогом и настройками)?

Всё можно описать тремя видами уравнений:
1. value = other_value // одностороннее равенство
2. value == other_value // двухстороннее равенство
3. values... = f(other_values...) // односторонняя эквивалентность
Выражение двухсторонней эквивалентности требует двух уравнений, из которых при решении системы выбирается то, что соответствует направлению изменений.

Вывод: требуется решатель системы уравнений для синхронизации изменений между равноценными информационными объектами.

Что касается практических примеров, то взаимодействие данные-данные удобно посмотреть в САПРах, в частности, dependency graph в Autodesk Maya. А последний шаг взаимодействия данные-визуализация прекрасно иллюстрируется в WPF (AffectMeasure, AffectsRender, ...).


  • 1
ex0_planet March 1st, 2014
А не будет ли там банальный DAG, по которому надо просто оптимальным образом распространить изменения?

И, да, программирование — это наука о том, что и где закэшировать :-)

justy_tylor March 1st, 2014
Нет. В виде DAG представляется propagation одного изменения, т.е. при изменениях в разных точках dependency graph это каждый раз будет разный DAG. По части оптимальности можно посмотреть push-pull модель в Maya.

ex0_planet March 1st, 2014
графом оно становится, вроде бы, только если разрешить глобальные переменные (см "настройки приложения") которые по сути являются просто одной из policy кэширования.

DAG, понятно, будет динамический.

justy_tylor March 1st, 2014
Графом зависимостей оно становится по причине интерактивности. Для анимации f(t) было бы достаточно DAG.

и чем это будет отличаться

Serge Shikov March 2nd, 2014
От того, что у же есть во Flex?

  • 1
?

Log in

No account? Create an account