On Wed, Sep 06, 2006 at 04:12:41PM +0400, Sergey Bolshakov wrote: > >>>>> "Stanislav" == Stanislav Ievlev <inger-u2l5PoMzF/[EMAIL PROTECTED]> > >>>>> writes: > [skipped] > > >> Выглядит обещающе. > >> Вероятно, есть смысл приготовить по такому рецепту несколько > >> стандартных контроллеров. Бишь, для приведенного view было > >> бы полезно иметь дополнительную логику вроде валидатора значения. > > Ага, я тоже подумал насчёт валидаторов. Видимо они должны быть опцией в > > контроллере. > > А тут уже можно подумать о xml-rpc для бакендов, которые и выдавали бы > некую метаинформацию о окучиваемых ими данных. А не всё-равно через какой протокол передавать ;) > > >> > >> Затем, построение 'конгломерата' могло бы быть упрощено > >> за счет выкидывания перечисления набора из simple-property > >> и замены на некую автоматику -- в предположении, что бэкенд > >> умеет показать структуру своих данных, например, через woo-read-names. > >> В будущем имело бы смысл, как мне кажется, иметь выделенную фазу > >> автоподстройки уровней друг под друга в рантайме. > > Это видимо в будущем. Для точного определения типа параметра надо будет > > подтачивать бакенды, возможно действительно путём передачи наверх > > точного параметра. > > Аналогично. > > >> > >> Затем, было бы полезно иметь некий механизм описания > >> взаимозависимостей набора (not-so-)simple-property, > >> поскольку реальный мир редко сводится к табличке в нормальной > >> форме :) > > Согласен. Тут есть два варианта. > > Взаимосвязь делать на уровне "модели" (в терминах MVC, а не по жизни), > > которую сейчас представляет woo. Или на уровне "контроллера". Какие будут > мысли? > > Depends. Видимо, нужны оба варианта: > - в модели, когда знание о взаимосвязи у нас в голове (скажем, > данные из бакенда приходят в виде плоской таблицы, поскольку у нас > нет желания размещать там дополнительную логику) > > - в бэкенде по факту, пример -- evms, где логика уже реализована > в libevms и наружу выдаётся результат взаимодействия заказанных > нами значений таких property. Я тут подумал, что если свящи размещать в модели то это выльется в то что сейчас в evms. То есть при каждом запросе надо будет проверять на наличие side-effects и при необходимости передёргивать все атрибуты назад (со всеми их свойствами, например, насколько помню могут измениться ограничения, но не значения).
Видимо это крайний вариант, надо думать на предмет контроллера в качестве базового. > > -- > _______________________________________________ > Devel-conf mailing list > [email protected] > https://lists.altlinux.org/mailman/listinfo/devel-conf _______________________________________________ Devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
