Комментарии 7
А причем тут RHCP? :)
Теперь надо делать следующий шаг - надо разделить визуальный виджет и логику его наполнения. Чтобы один и тот же визуальный виджет могли использовать разные команды и они сами могли определять откуда и по каким правилам он будет наполняться содержимым.
Я правильно понимаю что BDUI это современная реинкарнация HATEOS?
Проблема в том, что подобные решения пригодны только для унифицированного интерфейса. Например, для старых банковских терминалов или текстовых консолей.
Интерактивность и разнообразие пользовательских сценариев неизбежно приведёт к тому что вам придется выбрать одну из стратегий:
Клепать на каждый сценарий отдельный виджет
Делать конфигурацию виджетов гибче и подробнее
Вторая не рабочая, потому что ведёт к изобретению собственного языка разметки вроде HTML. Это бессмысленная работа, проще реализовать механизм динамического обновления клиента на используемом стеке UI.
Для решения этой проблемы мы решили собраться и подумать, а что у нас получилось - в следующей статье
Было бы интересно почитать что у вас получилось.
Не очень понял, почему гибкие конфигурации - это плохо. На больших проектах (и не только) есть дизайн системы, как раз ДС прекрасно ограничивает возможности, не нужно до бесконечности спускаться в кастомизацию.
Да и с виджетом на каждый сценарий тоже плохого ничего не вижу, это не даст возможности выкатить фичу с нулевым ТТМ, но зато даст остальные профиты виджетов (удобная интеграция, параллельная загрузка и тд).
Огонь! Спасибо, очень познавательно!
Как катить фичи без релизов. Часть 1: про виджеты