Здравствуйте, VladD2, Вы писали:

VD>Кроме того надо учитывать, что на сегодня, современные страницы обычно являются контейнерами для нескольких виртуальных страниц данные для которых могут передаваться асинхронно.

VD>Мне видится, что лучшим средством передачи данных между клиентом и сервером будут является REST-подобные пакеты содержащие некоторые иерархически оформленные данные.

VD>Однако данные на клиенте у нас лежат в виде плоских списков (таблиц) записей (кортежей с именованными полями) и реляционных отношений между ними.

Имхо, это все проще решается через аякс. Более сложные решения с виртуальными страницами нужны крупным компаниям, которым OSS проект точно не нужен.

VD>Таким образом первой задачей стоящей перед веб-разработчиком стоит преобразование плоских данных из БД (и возможно других источников информации) в иерархические структуры данных.

VD>Одним из требований к иерархическим структурам данных (далее ИСД) является полная статическая типизация и доступность расширенной метаинформации. Скажем для строковых полей должна быть доступна информация о максимально и минимальной длинне, маска ввода и т.п. Так же должна быть доступна информация о том допускается ли опускать значения (не дурацкие NULL из БД, а аналог option[T]). Но статическая типизация важнее.

VD>Большим, не решенным вопрос остается — нужно ли описывать ИСД или имеет смысл создавать аналогично экземплярам анонимных типов.

У меня есть не до конца оформившиеся мысли про анонимные типы и duck typing. Идея в том, иметь свой динамический анонимный тип генерируемый для каждой вьюхи и связывать его с статичными классами описывающим метаинформцию.

VD>С одной стороны явная декларация будет полезна так как предоставит метаинформацию для следующих этапов обработки.
VD>С другой стороны таких структур будет много и меняться они будут тоже очень часто, так что чтобы добавить поле придется изменить запрос и определение этой структуры вместо того чтобы изменить только один запрос.

VD>ИСД должны автоматическим образом преобразовываться в ХМЛ или Джейсон и обратно. При обратном преобразовании должна производиться проверка корректности данных с выдачей списка сообщений об ошибках (которые потом можно будет отобразить на клиенте).

Эти 2 пункта лучше не смешивать.

VD>Данный движок должен работать как на сервере, так и на клиенте. На клиенте, естественно, его код должен преобразоваться в выполняющий аналогичные действия ЯваСкрипт.

У меня большие сомнения в подобных абстракциях.