Данное сообщение ставит своей целью только высказать свои мысли. Не воспринимайте его слишком строго и уж тем более как навязывание идей.
Мое видение NRails
Для начала проанализируем задачу. У нас есть:
1. Данные хранящиеся приемущественно в СУБД (доступ к которым ведется через БЛТулкит), данные хранимые в виде файлов или получаемые от других систем.
2. Некоторый код на сервере отвечающий за: а) формирование данных для клик (представление); б) обработку данных клиента (контроллер); в) организацию процесса навигации по страницам (глобальный воркфлоу) и т.п. (контроллер).
3. Некоторый клиентский код отвечающий за формирование динамического UI, общение с сервером и организацию локального воркфлоу.
Кроме того надо учитывать, что на сегодня, современные страницы обычно являются контейнерами для нескольких виртуальных страниц данные для которых могут передаваться асинхронно.
Мне видится, что лучшим средством передачи данных между клиентом и сервером будут является REST-подобные пакеты содержащие некоторые иерархически оформленные данные.
Однако данные на клиенте у нас лежат в виде плоских списков (таблиц) записей (кортежей с именованными полями) и реляционных отношений между ними.
Таким образом первой задачей стоящей перед веб-разработчиком стоит преобразование плоских данных из БД (и возможно других источников информации) в иерархические структуры данных.
Одним из требований к иерархическим структурам данных (далее
ИСД) является полная статическая типизация и доступность расширенной метаинформации. Скажем для строковых полей должна быть доступна информация о максимально и минимальной длинне, маска ввода и т.п. Так же должна быть доступна информация о том допускается ли опускать значения (не дурацкие NULL из БД, а аналог option[T]). Но статическая типизация важнее.
Большим, не решенным вопрос остается — нужно ли описывать ИСД или имеет смысл создавать аналогично экземплярам анонимных типов.
С одной стороны явная декларация будет полезна так как предоставит метаинформацию для следующих этапов обработки.
С другой стороны таких структур будет много и меняться они будут тоже очень часто, так что чтобы добавить поле придется изменить запрос и определение этой структуры вместо того чтобы изменить только один запрос.
ИСД должны автоматическим образом преобразовываться в ХМЛ или Джейсон и обратно. При обратном преобразовании должна производиться проверка корректности данных с выдачей списка сообщений об ошибках (которые потом можно будет отобразить на клиенте).
Для генерации хмл/хтмл нужно создать движок рендера который должен быть чем-то вроде StringTemplate, но оперирующий не строками, а ХМЛ-ем (например, XElement).
Выглядеть это дело должно примерно так:
Page1(commonData: ?, users : list[User]) : XElement <#
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">...
<title>$(commonData.TitlePrefix)Пользователи</title>
</head>
<body>
$(RandrUsers(users))
</body>
</html>
#>
RandrUsers(users : list[User]) : XElement <#
<ul>
<li foreach="users">$SurName $FName $(DateTaimePiker(Age)) </br>
$(RandrAddress(Addresses))
</li>
</ul>
#>
RandrAddress(addresses : list[Address]) : XElement <#
<ol if="!addresses.IsEmpty">
<li foreach="addresses">$Street, ...</li>
</ol>
#>
Данный движок должен работать как на сервере, так и на клиенте. На клиенте, естественно, его код должен преобразоваться в выполняющий аналогичные действия ЯваСкрипт.
