[Devel-conf] alterator и его требования (was описание структуры бакенда на примере пользователей)

[Stanislav Ievlev]

Опять треды не рвёте ;)

Официального ТЗ к alterator нет, но основные задачи его в течении
времени не менялись. Просто по мере движения мир меняется, у
пользователей возникают новые требования, старое красивое ТЗ
(сделанное voins и george) давно уже рассыпалось в прах.

Это должен быть построитель решений на базе дистрибутивов ALT Linux.

Пользоваться этим конструктором должен быть в состоянии пользователь
не владеющий глубокими познаниями в программировании, зато прекрасно
понимающий свои админские задачи и умеющий решать их при помощи
известных средств автоматизации, включая shell.
С бакендами в общем-то проблем никаких нет. Они практически без
изменений живут вот уже несколько лет и большинство пользователей
устраивают за небольшими исключениями как-то:
хотелось бы добавить типизацию и иметь некоторое декларативное
описание структуры бакенда (это собственно и обсуждается)

Вторая задача иметь возможность этому же гипотетическому админу также
легко и без проблем строить к своему бакенду интерфейс и интегрировать
его в общую среду управления. Крайне желательно чтобы человек сразу
получал интерфейс и графический и http.

Вот с этим проблема. Уже много спобобов было перепробованно - не один
не показал себя с лучшей стороны. Главная проблема: какую-бы
обалденную модель, view и controller мы не придумали. На выходе
хочется получать "гибкий и отзывчивый" интерфейс. То есть меньше чем
на MacOSX мы (то есть руководители) не согласны ;)

А отсюда получается, что при описании интерфейса так или иначе
возникает  не слабое программирование. Единственное до чего я сейчас
дозрел - что это программирование надо вести на JavaScript - понятный
большинству людей язык программирования.

Кроме того проблема: GUI и WUI очень сильно отличаются. Настолько
сильно, что хоть M хоть V хоть C, невозможно сделать систему одинаково
хорошую и для первого и для второго.

Есть способ задействовать мощные средства Ajax типа QuiX или qooxdoo и
сымитировать GUI , но на этом проблемы не заканчиваются. layout
отличается настолько, что либо в конечном итоге вы напишете свой
web-браузер на qt либо всё будет тормозить на web.

Последние мои мысли тут - отказаться от сферического коня. Сделать
акцент на http. Последние продвижения на ниве Ajax позволяют сделать
гибкий интерфейс, а наличие плагинов к браузерам позволяет сделать
фокусы которые раньше были возможны только для gui (например
посмотрите модуль настройки x11 и xkb в desktop 4.0).

Теперь про MVC и RoR . Смотрел я эти штуки. За исключением двух-трёх
идей не понравилось.
Для бакендов мне MVC не нужен - лучше я сделаю возможность из одного
бакенда вызывать другой - моделирование получается на порядок лучше.
А для интерфейсов - MVC - убийственная для простого пользователя вещь,
особенно если мы хотим получить интерфейс типа MacOSX. Поглядите на
ItemViews - это красивая, необычайно гибкая, но тяжёлая в
программировании и понимании этого штука. Это не для людей - это для
программистов.

RoR заточен под конкретную задачу. Да, он многое под эту задачу
автоматизирует, но в нём: шаг вправо, шаг влево - смерть.
Автоматизация там доведена до крайности - чего стоит только
распознавание множественного числа. Я такого не хочу ;)

Ну и напоследок про alterator-fbi.
Никогда не скрывалось, это писалось как хак ибо не успевали с
http-интерфейсом (QuiX и qooxdoo оба провалились;) ).
Однако он не так плох как некоторые считают, а местами даже
превосходит MVC сделанное в RoR и опытом этим нельзя пренебрегать.

В fbi отдельно представление и собственно workflow (динамика виджета)
+ практически автоматическая привязка frontend к backend. worklflow
там можно использовать повторно, если бы не это - никогда бы не было
Server 4.0.

Из неудобных вещей в fbi я знаю только:
1. необходимость писать workflow на scheme - это не для всех
пользователей возможно.  Есть наработки чтобы писать всё это на
Javacsript в модели DOM - это должно быть доступно всем.
2. наличие бакендов-"спутников" - это был хак, чтобы скомпенсировать
немного пункт 1.

итак есть View (http-шаблон) и есть Controller (workflow).  Оба на
голову выше старинной модели шаблонов в RoR.

Есть в alterator и Model - это бакенды. Над ними надо ещё поработать.
Собственно процессс идёт.