>>>>> "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. -- _______________________________________________ Devel-conf mailing list [email protected] https://lists.altlinux.org/mailman/listinfo/devel-conf
