Я такое делал на работе, и для себя. На питоне. Работает. Весьма компактный код получается.
Проблемы традиционные - непонимание подхода дизайнерами, необходимость ООБД на серверной стороне, необходимость дублировать state клиента на серверной стороне (при 10000 клиентах это напрягает), еще хочется сделать автоматическое размазывание обновлений (чтобы скрипт по возможности интерпретировался и на сервере, и на клиенте, уменьшая лаг) - это применительно к ММО игрушкам, но уменьшать лаг интерфейса везде хорошо.
А, да, дерева недостаточно, если хочется уменьшать дублирования, то получается граф из данных и функторов-"видов".
В HTML хорошо начинать пробовать, там можно сделать дерево тэгов и простейший javascript который poll'aет изменения и делает $(update.id).innerHTML = update.data
Так проще. Т.е. структуры в ООБД прямо соответствуют графу у клиента, и всё.
Можно просто поначалу мешать данные и представление, можно делать шаблоны, параметризуемые другими графами (но если пытаться соблюсти консистентность поведения и на шаблоне, и на том, что он сгенерировал - т.е. дать возможность генерировать другие шаблоны - лично у меня на этом этапе поехала крыша и я забил :))
Я что-то похожее делал. Там действительно хорошо подходит diff по деревообразной структуре и его преобразование из описания объекта в описание UI.
Основная проблема в итоге оказалась - мы получаем легкость изменения структуры(добавить поле в объект, добавить новый тип объектов) ценой сложности изменения мелочей, без изменения структуры. Т.е., например, нужно к полю ввода справа добавить непредусмотренную ранее кнопку навроде "прочитать данные из железа", причем чтобы это дело не сломало расположение элементов, было аккуратно выровнено, итд. Или просто добится красивого выравнивания. Если делать UI в дизайнере - это просто, если UI генерится - то приходится извращаться, и очень сильно. А дизайнеров, которые поддерживали бы складывание "структуры документа" и "оформления, таблицы стилей" - нету. Единственный вариант - писать самому, а в промышленной разработке самостоятельно делать не принято. "Пишите на том, что есть".
А, еще оказалось, что при отладке - это все превращается в ад. Когда идет линейная последовательность действий типа "создать кнопку, поставить ей такие-то координаты, создать следующий элемент управления,..." то достаточно поставить брекпоинт в нужное место и посмотреть, что идет не так. А когда это делается в цикле по списку описаний полей, да где-нибудь в глубине структуры, уровне так на третем-четвертом, да еще для каждого поля вызывается свой метод инициализации, то иначе как выводом в лог и медитацией на него ничего понять нельзя.
В итоге, лучше бы получилось, если из описаний структуры объектов генерировать код, он получался бы линейный и понятный, но вручную писать не нужно.
Comments 13
Я такое делал на работе, и для себя. На питоне. Работает. Весьма компактный код получается.
Проблемы традиционные - непонимание подхода дизайнерами, необходимость ООБД на серверной стороне, необходимость дублировать state клиента на серверной стороне (при 10000 клиентах это напрягает), еще хочется сделать автоматическое размазывание обновлений (чтобы скрипт по возможности интерпретировался и на сервере, и на клиенте, уменьшая лаг) - это применительно к ММО игрушкам, но уменьшать лаг интерфейса везде хорошо.
А, да, дерева недостаточно, если хочется уменьшать дублирования, то получается граф из данных и функторов-"видов".
В HTML хорошо начинать пробовать, там можно сделать дерево тэгов и простейший javascript который poll'aет изменения и делает $(update.id).innerHTML = update.data
Reply
Насчёт ООБД на серверной стороне - это прямо обязательное условие?
Насчёт графа я подумаю, но мне кажется, что можно будет обойтись и так.
И про HTML я тоже подумал в первую голову. ;)
Reply
Так проще. Т.е. структуры в ООБД прямо соответствуют графу у клиента, и всё.
Можно просто поначалу мешать данные и представление, можно делать шаблоны, параметризуемые другими графами (но если пытаться соблюсти консистентность поведения и на шаблоне, и на том, что он сгенерировал - т.е. дать возможность генерировать другие шаблоны - лично у меня на этом этапе поехала крыша и я забил :))
Reply
Основная проблема в итоге оказалась - мы получаем легкость изменения структуры(добавить поле в объект, добавить новый тип объектов) ценой сложности изменения мелочей, без изменения структуры. Т.е., например, нужно к полю ввода справа добавить непредусмотренную ранее кнопку навроде "прочитать данные из железа", причем чтобы это дело не сломало расположение элементов, было аккуратно выровнено, итд. Или просто добится красивого выравнивания. Если делать UI в дизайнере - это просто, если UI генерится - то приходится извращаться, и очень сильно.
А дизайнеров, которые поддерживали бы складывание "структуры документа" и "оформления, таблицы стилей" - нету. Единственный вариант - писать самому, а в промышленной разработке самостоятельно делать не принято. "Пишите на том, что есть".
Reply
В итоге, лучше бы получилось, если из описаний структуры объектов генерировать код, он получался бы линейный и понятный, но вручную писать не нужно.
Reply
Проверил по отдельности функции, собрал - всё заработало. ;)
В общем, рад, что не совсем идиотская идея. ;)
Reply
Как только начинает хотеться, чтобы у юзера не сбрасывался фокус, когда меняется текст в текстбоксе, который он прокручивает, например.
Reply
Reply
Reply
Reply
Reply
Leave a comment