Привет всем!
В независимости от того как захочется в будущем году изменить архитектуру
alterator (а может быть и вообще переписать всё заново) останется пачка
модулей (читай накопленного опыта и тайных знаний), а у модулей останется
интерфейс. И всегда останется проблема, что хороший интерфейс сделать
гораздо сложнее, чем сделать бакенд.
Также, единосекундно все модули врядли получится переделать на новые рельсы,
поэтому придётся всё делать постепенно. Несмотря на все заверения что такого
не бывает, я считаю, что это возможно и делаю это уже несколько лет.
Ещё момент: самое ценное в любом конфигураторе не движок, а его модули.
Поэтому предлагаемая схема расчитана на поддержку длительного существования
модулей в мире меняющихся "движков".
Итак, сейчас имеет место следующая картина:
1. В html есть статическое описание, которое делать достаточно просто и
workflow к нему. Касательно последнего: с одной стороны есть некие готовые
workflow которые подходят в большом количестве случаев. С другой стороны,
несмотря на наличие возможности делать свои workflow, воспользоваться ей
стараются пользоваться далеко не все. Помимо того что я просто-напросто не
рекламирую этой возможноти, это связано прежде всего с тем пишутся эти
workflow не очень просто. Тем не менее это самые обычные модули guile,
которые понятно как расширять.
2. В qt нет удобного статического описания, которое можно было бы посмотреть
и сделать в каком-нибудь редакторе интерфейса, фактически есть только одно
workflow. Как делать это workflow вроде как более менее понятно и
разобраться в этом можно, но несмотря на то что это как бы схема, это есть
неудобное подмножество схемы c искуственными ограничениями, которое очень
неудобно расширять и не все догадываются во что "это" превращается, когда
оно доберётся до eval и как следствие отлаживать всё это хозяйство
затруднительно.
Отсюда есть мысли, что надо сделать лучший из этих двух миров и заодно
сделать очередной шаг по сближению qt и html интерфейсов.
1. workflow для qt оформить как самые обычные модули guile. Схема эта уже
отработана на workflow для qt, на системе типов и на нативных бакендах.
Желающие могут посмотреть в
/usr/share/alterator/interfaces/guile/{type,workflow}
Заодно планируется избавиться от странной схемы:
/usr/share/alterator/interfaces/guile. Она была создана в момент творческих
поисков и попытки уйти от guile.
Будет /usr/share/alterator и там lib,ui, откуда грузяться модули guile.
2. workflow для html также планируется "приблизить к серверу", чтобы снять
ряд искуственных ограничений. Вместо того чтобы расширять список
передаваемых workflow аргументов (url url-args, template-args, а теперь бы
ещё и htttp-args и query-args), оно будет получать просто то самое сообщение
которое пришло к серверу и template-args ( параметры переданные самому
workflow)
3. можно сделать следующую схему расположения описаний:
* <стандартный каталог>/url/index.scm - тут могут обитать workflow для qt и
для html. При обращении по урлу будет сначала пытаться загрузиться отсюда
нужный вид workflow. (со временем я надеюсь эти два workflow окончательно
объединятся). В принципе можно сделать так что эти workflow будут брать
статические описания формы из каких-то файлов вызывая стандартные функции.
Это может быть общее для qt и для html описание в формате xml (да хоть xul),
а может быть стоит иметь описания в таком виде что их легко создавать
визуальными средствами типа qt designer. В общем это непаханное поле для
размышлений. Я считаю что надо пробовать разные варианты - только так будет
ясно что лучше.
* <стандартный каталог> /url/index.html - статическое описание, в котором
есть ссылка на некий стандартный workflow. Этот вариант может существовать в
переходный период для целей html, пока не будет придумано какого-нибудь
"идеального" описания интерфейса. А ещё лучше , если этот вариант так и
останется как один из быстрых способов "слепить" форму.
* <стандартный ксталог>/url/index.{js,py,java} - если вдруг кто-то сделает
что-то новое и хорошее то можно будет рядом положить workflow и на этот
случай. Как следствие модуль, сможет после этого жить и с другим "движком".
При условии что будет сделана хорошая библиотека поддержки workflow,
описание workflow для каждого конкретного модуля не должно будет занимать
много места и миграцию с одного "ядра" на другое можно будет делать
относительно быстро и даже при желании поддерживать несколько систем
одновременно.
--
Станислав Иевлев.
_______________________________________________
devel-conf mailing list
[email protected]
https://lists.altlinux.org/mailman/listinfo/devel-conf
