Пара мыслей на счет дизайна NRails - Nemerle

Данное сообщение ставит своей целью только высказать свои мысли. Не воспринимайте его слишком строго и уж тем более как навязывание идей.

Мое видение 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>
#>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

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

Еще неплохо было бы продумать вопрос генерации форм, клиент-серверную валидацию и Scaffolding на основе этого.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

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

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

Я тут опечатался. Не "на клиенте", а "в СУБД".

Так что причем тут аякс я вообще не понимаю.

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

Одного типа (анонимный или нет без разницы) тут будет мало. Тут напрашивается или генерация иерархии типов, или использование чего-то рекурсивно-древесного вроде ХМЛ (но дополненного типизацией).

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

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

Не вижу особой разницы. В обоих случаях получается сериализация.

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

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

Вот сомнения интересны менее всего. Интересны конкретные аргументы.

Что касается абстракций вообще, то чем они луче, тем лучше.

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

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

D>Еще неплохо было бы продумать вопрос генерации форм,

А чем генерация форм должна отличаться от генерации чего-то еще?

D>клиент-серверную валидацию

Об этом я уже написал. Если в ИСД будут необходимые метаданные, то проверку вводимых данных можно будет организовать на их базе (как на клиенте, так и на сервере).

D>и Scaffolding на основе этого.

Кстати, кто-нить может дать полноценный перевод этому термину?

Как я понимаю этот Scaffolding — это что-то вроде генерации заглушек кода.

В студии для этих целей обычно используются разные визарды, а в Рубли командная строка. Так?

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

VD>Так что причем тут аякс я вообще не понимаю.

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

Для большинства случаев эти виртуальные страницы проще запросить на клиенте, чем строить асинхронную логику во вьюхах. Для этого лучше отдельный сервер для вьюх иметь, как писал WolfHound про яндекс. Но это оверкил для KISS&DRY ориентированного фреймворка.

VD>Одного типа (анонимный или нет без разницы) тут будет мало. Тут напрашивается или генерация иерархии типов, или использование чего-то рекурсивно-древесного вроде ХМЛ (но дополненного типизацией).

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

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

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

VD>Не вижу особой разницы. В обоих случаях получается сериализация.

В смысле не смешивать десериализацию и валидацию. Для валидации в мвц уже много всего, пусть оно и занимается, надо только помочь слегка.

VD>Вот сомнения интересны менее всего. Интересны конкретные аргументы.
VD>Что касается абстракций вообще, то чем они луче, тем лучше.

Ок, давай конкретнее. Типичные задачи на клиенте:

заменить контент в нужном месте DOM
загрузить готовый контент в нужное место DOM
создать новый элемент в нужном месте DOM и наполнить его контентом
всякие визуальные эффекты, скрыть, показать, поменять стиль

На сервере нужна только одна из них и та частично: создать новый элемент DOM без явного указания конкретного его положения.

Слишком разные задачи, чтобы пытаться их делать одинаковым способом.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

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

Z>я писал про...

Ну, так и цитируй то что нужно.

Z>Для большинства случаев эти виртуальные страницы проще запросить на клиенте, чем строить асинхронную логику во вьюхах.

Зачем строить асинхронную логику? Нужно просто иметь возможность отдать нужные данные. Асинхронным все станет само собой (так как страница будет запрашивать данные асинхронно).

Z>Для этого лучше отдельный сервер для вьюх иметь, как писал WolfHound про яндекс. Но это оверкил для KISS&DRY ориентированного фреймворка.

Зачем отдельный? И в чем тут оврекил?

Мы имеем простейшую REST-схему. Данные из БД => ИСД => рендеринг ХТМЛ-а или отправка данных на клинета через скрипты.

Проще не куда. Дублироваться просто не чему.

VD>>Одного типа (анонимный или нет без разницы) тут будет мало. Тут напрашивается или генерация иерархии типов, или использование чего-то рекурсивно-древесного вроде ХМЛ (но дополненного типизацией).

Z>Под анонимным типом я тут подразумевал не стандартный анонимный, а тот, что будет генериться для вьюхи,

А зачем для вьюхи? В общем, опиши это по подробнее. Лучше с примерами (на псевдокоде).

Z>естественно он будет служить контейнером для других автосгенеренных "анонимных", степень вложенности тут ограничивается только программистом.

Как данные могут служить контроллером и зачем?
И с чего будут генерироваться эти типы? Что будет служить описанием для них?

VD>>Не вижу особой разницы. В обоих случаях получается сериализация.

Z>В смысле не смешивать десериализацию и валидацию.

А. Ну, может быть. Хотя они по любому будут друг на друга завязаны.

Z> Для валидации в мвц уже много всего, пусть оно и занимается, надо только помочь слегка.

Я не знаком с МВЦ, так что мне тяжело судить. Но если можно сделать лучше, то мне кажется, не нужно замыкаться на их реализацию.

Z>Ок, давай конкретнее. Типичные задачи на клиенте:
Z>

заменить контент в нужном месте DOM
Z>

загрузить готовый контент в нужное место DOM

В чем разница?

Z>

создать новый элемент в нужном месте DOM и наполнить его контентом
Z>

всякие визуальные эффекты, скрыть, показать, поменять стиль
Z>

Z>На сервере нужна только одна из них и та частично: создать новый элемент DOM без явного указания конкретного его положения.

Z>Слишком разные задачи, чтобы пытаться их делать одинаковым способом.

В данном случае ты смотришь с точки зрения конеретной реализации.

На мой взгляд разработчика нужно защитить от знаний DOM-а. Нужно создать некий абстрактный слой, назавем его плэйсхолдер, и дать людям удобный АПИ по замене содержимого этих плэйсхолдеров.

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

VD>>Вот сомнения интересны менее всего. Интересны конкретные аргументы.
VD>>Что касается абстракций вообще, то чем они луче, тем лучше.

Z>Ок, давай конкретнее. Типичные задачи на клиенте:
Z>

заменить контент в нужном месте DOM
Z>

загрузить готовый контент в нужное место DOM
Z>

создать новый элемент в нужном месте DOM и наполнить его контентом
Z>

всякие визуальные эффекты, скрыть, показать, поменять стиль
Z>

Z>На сервере нужна только одна из них и та частично: создать новый элемент DOM без явного указания конкретного его положения.

Z>Слишком разные задачи, чтобы пытаться их делать одинаковым способом.

Да... собственно я так и не понял в чем сомнения?

Итак для динамики нам нужно:
1. Гонять данные между броузером и сервером в виде ХМЛ/Джейсон. Эту задачу решают предложенные мной ИСД (иерархические структуры данных) которые умеют автоматом серилизоваться и загружаться из ХМЛ и джейсон.
2. Наличие неких плэйсхолдеров в ДОМ-е и АПИ позволяющее заменять их контент.
3. АПИ которое позволит нам быстро, просто и качественно преобразовать данные в формате ХМЛ/джейсон в ХТМЛ который будет подставляться в плэйсхолдеры.

Третий пункт мало чем отличается от задач выполняемых на сервере. Для этой задачи на сервере ты предлагаешь использовать движок рендеринга аля СтрингТемплэйт. Ну, так почему бы не создать такой же движек работающий на клиенте?

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

VD>А чем генерация форм должна отличаться от генерации чего-то еще?

Тем что это отдельный механизм со своей логикой.
Для

class Person { public string [Display("Name")][MaxLength(100)] Name {get;set;}

Должно сгенерироватся лейбл, инпут и правильный name для него, плюс джаваскрипт для проверки валидности на клиенте.

VD>Кстати, кто-нить может дать полноценный перевод этому термину?

VD>Как я понимаю этот Scaffolding — это что-то вроде генерации заглушек кода.

VD>В студии для этих целей обычно используются разные визарды, а в Рубли командная строка. Так?

Перевод не скажу, но это автоматическая генерация интерфейса для работы с базой, аля админка.
Net аналоги Dynamic Data и Data Forms

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

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

D>Тем что это отдельный механизм со своей логикой.
D>Для
D>

D>class Person { public string [Display("Name")][MaxLength(100)] Name {get;set;}
D>

D>Должно сгенерироватся лейбл, инпут и правильный name для него, плюс джаваскрипт для проверки валидности на клиенте.

Display явно лишний.

Что до сгенерировать, то формы тут ничем не должны отличаться от чего-то другого. Просто когда мы будем генерировать код поля, то шаблон должен уметь прочитать метаданные из описания поля модели и сгенерировать необходимый код проверки.

Но такой механизм должен быть общим (не только для форм, а для всего).

Именно по этому важно, копируя и преобразуя данные копировать (сохранять) метаданные.

В упомянутых мной ИСД так же должна присутсвовать метаинформация которая должна или определяться явно (при их описании) или копироваться с классов модели БЛТулкита.

D>Перевод не скажу, но это автоматическая генерация интерфейса для работы с базой, аля админка.
D>Net аналоги Dynamic Data и Data Forms

Что-то мне опдсказывает, что этот скафолдинг — фуфло. Лучше было бы сделать так, чтобы некий шаблон/макрос мог принять на вход конкретный ИСД и на выходе выдать готовую страницу со всеми фенками редактирования. А пользователи пусть вместо правки сгенерированных скафолдингом заглушек создают собственные шаблоны которые будут иметь нужное им поведение.

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

VD>Display явно лишний.
Очевидно что там может быть все что угодна, скорее всего логализованая строка из ресурсов.

VD>Что-то мне опдсказывает, что этот скафолдинг — фуфло. Лучше было бы сделать так, чтобы некий шаблон/макрос мог принять на вход конкретный ИСД и на выходе выдать готовую страницу со всеми фенками редактирования. А пользователи пусть вместо правки сгенерированных скафолдингом заглушек создают собственные шаблоны которые будут иметь нужное им поведение.

Никто и не говорит о правке, все генерируется в рантайме на основе шаблонов.

Например человек может определинть шаблоно DateTime.ascx и описать как будет выгдятиь контрол для даты.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, VladD2, Вы писали:
Что бы уточнить действительно ли мы говорим об одном и том же.
Мной предлагается что неплохо бы иметь такой механизм, который бы с помощью пары строк кода сгенерил бы автоматом форму для

class Person{
    public string Name {get;set;}
     
    public List<Contact> Contacts {get;set;}
} 

class Contact {
public string Value {get;set;}

public int TypeID {get;set;}
}

Что бы в итоге получился один текстбокс для имени и таблица с контактами в каждой строке текстбокс и комбобокс с типами контактов, и джаваскриптом добавлять удалять строк. Да еще и валидация Value в зависимости от TypeID

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

D>Очевидно что там может быть все что угодна, скорее всего логализованая строка из ресурсов.

очевидно, что строки из ресурсов лишние в моделе. Им бы в представлении быть. Но идея ясна. Ассоциировать с некоторыми полями некоторые лэйблы для представлений. Это конечно можно, но такому описанию не место в описании модели.

VD>>Что-то мне опдсказывает, что этот скафолдинг — фуфло. Лучше было бы сделать так, чтобы некий шаблон/макрос мог принять на вход конкретный ИСД и на выходе выдать готовую страницу со всеми фенками редактирования. А пользователи пусть вместо правки сгенерированных скафолдингом заглушек создают собственные шаблоны которые будут иметь нужное им поведение.

D>Никто и не говорит о правке, все генерируется в рантайме на основе шаблонов.

Как в рнтайме? А зачем тогда там в командной строке что-то задается?

D>Например человек может определинть шаблоно DateTime.ascx и описать как будет выгдятиь контрол для даты.

Тогда я видимо плохо понимаю что значит этот скафолдинг.

Мне казалось они им генерируют код представлений и т.п.

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

D>>Очевидно что там может быть все что угодна, скорее всего логализованая строка из ресурсов.

VD>очевидно, что строки из ресурсов лишние в моделе. Им бы в представлении быть. Но идея ясна. Ассоциировать с некоторыми полями некоторые лэйблы для представлений. Это конечно можно, но такому описанию не место в описании модели.

В случае скаффолдинга для них другого места просто нет, т.к. view строится в рантайме.

VD>>>Что-то мне опдсказывает, что этот скафолдинг — фуфло. Лучше было бы сделать так, чтобы некий шаблон/макрос мог принять на вход конкретный ИСД и на выходе выдать готовую страницу со всеми фенками редактирования. А пользователи пусть вместо правки сгенерированных скафолдингом заглушек создают собственные шаблоны которые будут иметь нужное им поведение.

D>>Никто и не говорит о правке, все генерируется в рантайме на основе шаблонов.

VD>Как в рнтайме? А зачем тогда там в командной строке что-то задается?

Это в руби задается (вроде), а в том же динамик дата — на лету.

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

D>Мной предлагается что неплохо бы иметь такой механизм, который бы с помощью пары строк кода сгенерил бы автоматом форму для

D>

D>class Person{
D>    public string Name {get;set;}
     
D>    public List<Contact> Contacts {get;set;}
D>} 

D>class Contact {
D>public string Value {get;set;}

D>public int TypeID {get;set;}
D>}
D>

D>Что бы в итоге получился один текстбокс для имени и таблица с контактами в каждой строке текстбокс и комбобокс с типами контактов, и джаваскриптом добавлять удалять строк. Да еще и валидация Value в зависимости от TypeID

Ага, вроде того. Только с парой оговорок:
1. Подобную функциональность нужно иметь не только для форм, но и вообщем.
2. Нам нужно работать не с классами, а с их проекциями. Скажем если кто-то выполнил запрос и получил только список имен Person (в виде анонимного типа с одним полем), то чтобы если мы передадим этот список анонимных типов в такой генератор, чтобы он и таком случае сгенерировал проверки на клиенте. Для этого в запросах нужно копировать всю метаинформацию для возвращаемых полей.

Собственно анонимных типов хватит только для простых случаев. Так что нужны те самые иерархические структуры данных (ИСД). В них так же должна копироваться метаинформация из полей модели.

От:	VladD2	www.nemerle.org
Дата:	16.04.10 11:37
Оценка:

	От:	Ziaw
	Дата:	16.04.10 11:53
	Оценка:

	От:	dotneter
	Дата:	16.04.10 12:35
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	16.04.10 14:38
Оценка:

От:	VladD2	www.nemerle.org
Дата:	16.04.10 14:42
Оценка: