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

[Alexander Bokovoy]

Peter V. Saveliev пишет:
> Ключевой момент, который я не понимаю -- это уверенность в том, что код 
> _нужно_ генерировать. Причём в такой манере. Я не говорю, что она плохая, мне 
> просто кажется, что в данном случае это может быть слегка не в кассу.
Хочу отметить, что я не предлагаю выбрать тот или иной вариант (IDL), я 
просто продемонстрировал как с помощью IDL описываются интерфейсы, по 
которым генерируется связующий код -- связующий вызовы со стороны 
клиента и сервера (что бы под этим ни понималось). "Мотороллер не мой".

> Что нам нужно:
> 
>  * возможность написать "плоский" файл и карту, которая методы плоского файла 
> будет проставлять в соответствие стандартным методам узлов, как это принято в 
> движке.
> 
> Если по пути будет генериться код-скелетон для шелл-модуля -- хорошо, но он 
> должен получаться очень просто. А то, что я увидел выше -- само по себе код, 
> причём не самый простой (для такого тривиального случая).
Это описание интерфейса, а не код. пара структур и сигнатуры методов, 
использующих их (и пометки _как_ использующих).

> Если бы я собрался писать для альтератора и увидел бы этот пример -- я бы 
> крепко призадумался. Я не говорю, что IDL плохо. Просто меня это бы испугало: 
> невозможно знать всё, а этот пример требует явных усилий по изучению чего-то 
> не очень простого, что мне пока нигде не нужно было и вряд ли где-то ещё 
> пригодится. Учитывая, что последнее время я начал достигать порога насыщения, 
> для меня это потенциально тяжёлая ситуация.
Я тоже думаю, что IDL для подобной ситуации плох. Альтератор -- типичная 
задача для архитектуры MVC (модель-отображение-управление), только 
представление модели несколько размыто в связи с разнообразием областей 
применения -- там не всегда реляционные схемы и отношения между 
однотипными объектами, а потому описать одной типизацией ({элемент, 
итерируемая коллекция элементов}x{запрос,добавление,удаление}) не очень 
получается.

С другой стороны для типичного сферического разработчика MVC проще -- во 
многом потому, что на основе M можно автоматом сгенерировать V и потому 
сосредоточиться только на C. Для примера -- scaffold в RoR для 
произвольной модели автоматом генерирует просмотр-добавление-удаление 
набора табличных данных. При этом контроллер, который строит отображение 
этой модели выглядит так:

class EntryController < ApplicationController
   scaffold :post
end

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

Вот живое демо с кодом в стиле этой идеи: 
http://demo.activescaffold.com/users

Показываю ровно для того, чтобы проиллюстрировать идею, а не для 
предложения конкретного технического решения.
-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/