Re[11]: Пара мыслей на счет дизайна NRails - Nemerle

Здравствуйте, 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-а. Нужно создать некий абстрактный слой, назавем его плэйсхолдер, и дать людям удобный АПИ по замене содержимого этих плэйсхолдеров.

Здравствуйте, 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, Вы писали:

Z>>Чем JsonConvert.SerializeObject(объект) хуже макры?

VD>Лучше задаться вопросом чем он лучше. Кроме того что он есть я больше преимуществ не нахожу.

Это офигительный плюс. У меня очень ограниченные ресурсы.

Z>>Расскажи про сценарии в которых можно заменить jQuery более удобной вещью, с примерами.

VD>Ну, представь себе, что в твоем проекте вообще нет яваскрипта. Весь код на Немерле. При этом даже клиентские скрипты статически типизированы и проверяются при компиляции. При этом где-то в коде у тебя есть что-то подобное:

А как использовать фичи именно яваскрипта которые не умеет Nemerle? Вот у меня довольно сложная логика раскидана по классам, которые в яваскрипте нифига не классы, как мне ее на немерле переводить? Слишком разные языки. А сделать рендер вобщем-то да, можно. Выглядит неплохо.

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

Я предложу людям что-то удобнее MVC, с надеждой развития во что-то еще более удобное.

VD>Это домысли. Он по любому будет больше. Не могут быть данные равны или меньше чем их форматированное представление.
VD>А вот насколько он будет больше зависит от того насколько жирным окажется ХТМЛ.

Так данные форматированными передаются, тут идет вопрос какое форматирование жирнее. Жирнее XML сложно придумать.

VD>Это очковтирательство! ХТМЛ не бывает таким плоским. Он по любому будут содержать кучу разной фигнию.

Какой фигни? Всю фигню ему потом клиент навешает, стили, обработчики.

VD>Плсю ты что джейсон тоже хочешь в виде строк, врунчую генерировать?
Нет, это код, который может сделать макрос. Хтмл тоже я так генерить не собираюсь, но выход макры должен быть примерно таким.

VD>Вот сранви с кодом который должен быть по моим представлением:
VD>

VD>contriller.RegistrUrl(@"/somepage/secondpape", Format.Xml | Format.Json, GetData());
VD>

Не дело это в контроллере регистрить урл, роутинг уже есть. Выглядеть должно примерно так.

def Get(id : Guid)
{
    def model = db.Persons.Single(p => p.Id == id);
    ViewByFormat(model);
}

Вот и все, вернется то, что запрашивается, это определятется по заголовку Accept в реквесте или по дополнительному полю в запросе. Хтмл форматы будут могут быть описаны в одном view файлике или в одноименных формату файликах, на выбор пользователя.

Z>>Нужен лишь html который будет еще одним форматом представления продукта. Будет ли он рыхлым это выбор пользователя.

VD>Вот именно "еще одним". И только его и нужно описывать руками. Остальное (т.е. XML и JSON) должно быть декларативно.

С этим я и не спорил.

Z>>Тут ты прав, просто я уточнил, что рендер html на клиенте явление не столь частое

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

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

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

VD>Так же я не понимаю зачем писать сложный код на этих скриптах когда можно написать очень понятный кусок кода на дсл-е (рендерера) и получить все что нужно почти без программирования.

Ты видишь задачу только в рендере, а задачи как раз в хитрой динамике, я сейчас делаю онлайн заполнение excel файлов, так там клиентской генерации html на 1% крайне простого кода. Зато дофигища использования всяческих селекторов, переключений стилей, аякс запросов. Все это проще делать на jScript, это его родное занятие, и я не считаю его недоязыком по сравнению с немерлом.

VD>ХМЛ же тормозной только в твоем воображении. А так — это всего лишь иерархический формат. Если не обрабатывать его раком, то он очень удобен, быстр и безопасен (в отличии от джйсона, который по факту — код на явасктипте).

На яваскрипте его придется обрабатывать именно раком и он будет тормозить.

VD>И вообще, опять этот странный подход "я не понимаю зачем Х?". Пользователю удобно. Этого объяснения выше крыши.

Удобно — пусть возьмет готовую либу чтения xml, зачем я ее буду писать? Одному там будет нужен xpath, второму превращение в объекты, третьему трансформация. Это не дело для общего фреймворка.

VD>Пользователь может получить этот самый ХМЛ из каких-то других источников. С того же Яндекса, к примеру. И что мы прикажем ему делать?
VD>Та же фигня будет когда пользователю придется передать ХМЛ куда-то.

Передать как раз не проблема, .net прекрасно работает с XML.

VD>Я предлагаю просто в качестве основного ТЗ прописать простую вещь. Мы предоставляем сериализацию объектов в JSON и XML (HTML рассматриваем как разновидность ХМЛ-я).

Это просто один из хелперных макросов в одном из последних пунктов, зачем на нем циклиться, да еще объявлять основной фичей?

VD>Другими словами — не надо никакой рукопашной генерации XML и JSON. Единственное что можно допустить — это некую трансформацию структуры.

Где я писал про рукопашную генерацию xml или json?

VD>Но это все нужно делать после того как будет решен вопрос с прозрачной поддержкой БД. Как там на этом фронте?

Свойства модели генерируются, связи нет, впрочем в рельсах тоже нужно явно макры для такой генерации писать. Миграции в процессе, DSL уже готов, отлаживаю генерациюю DDL.

              create TestTable
              {
                  Id : Guid(pk);
                  Zip : string?(len = 10) = "zzzz";
                  Price : int = 10;
              }
              
              change TestTable
              {
                  change Zip : string(len = 20);
                  
                  // сейчас падает тут =) Нужно убивать констрейнты связанные с полем, 
                  // думаю как это красиво сделать
                  drop Price; 
              }
              
              drop TestTable;

Еще не до конца прописаны разные типы и много чего по мелочи, например дефолтные значения надо переводить СУБДшный формат. Или не надо, ибо часто хочется задать это именно в сиквеле

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

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

Z>А как использовать фичи именно яваскрипта которые не умеет Nemerle? Вот у меня довольно сложная логика раскидана по классам, которые в яваскрипте нифига не классы, как мне ее на немерле переводить? Слишком разные языки. А сделать рендер вобщем-то да, можно. Выглядит неплохо.

Class based OOP спокойно имитируется на ДжаваСкрипте. Вообще ДжаваСкрипт — это пластилин, в него можно отобразить практически любой код. Обратное — не справедливо, но и не требуется как-то.
Не говоря уж о том, что есть n-ое количество реализаций компиляторов в ДжаваСкрипт.

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

Мое видение 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, Вы писали:

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>Как в рнтайме? А зачем тогда там в командной строке что-то задается?

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

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

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

Ассоциацию можно сделать и отдельно.

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

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

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

VD>А смысл это делать на лету?

А смысл что то генерить а потом править? В Asp.net есть что то похожее, типа визардов для генерации вью, но имхо это бессмысленно, так как например у меня на сайте дизайн форм менялся три раза и переделывать их каждый раз руками было бы крайне не весело.

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

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

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

VD>>А смысл это делать на лету?

D>А смысл что то генерить а потом править?

Смысл в настройках и доработках. Иначе вообще никакого смысл что-то генерировать?

Тогда уж нужно просто иметь некие компоненты которые по делают морду по описанию. Но это ведь не скафолдинг?

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

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

VD>Ассоциацию можно сделать и отдельно.

Ассоциацию между чем и чем?

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

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

Добавилось в сущность еще одно поле, опять генерим и опять вручную вносим изменения?

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

L>Ассоциацию между чем и чем?

Между именами полей и значениями лэйблов для разных языков.

L>Добавилось в сущность еще одно поле, опять генерим и опять вручную вносим изменения?

Ну, такова суть рельсов. Если ничего не мерял, то можешь просто генерить.

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

VD>Смысл в настройках и доработках. Иначе вообще никакого смысл что-то генерировать?

VD>Тогда уж нужно просто иметь некие компоненты которые по делают морду по описанию. Но это ведь не скафолдинг?

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

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

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

VD>Ну, такова суть рельсов. Если ничего не мерял, то можешь просто генерить.
А зачем тогда что то вообще генерить, думается мне что должна быть в рельсах поддержка генерации в рантайме.

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

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

L>>Ассоциацию между чем и чем?

VD>Между именами полей и значениями лэйблов для разных языков.

Можно и отдельно, но тогда нужно отдельно позаботиться о том, чтобы при переименовании полей менялась и соответствующая ассоциация.

L>>Добавилось в сущность еще одно поле, опять генерим и опять вручную вносим изменения?

VD>Ну, такова суть рельсов. Если ничего не мерял, то можешь просто генерить.

В динамик дата — по другому.

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

VD>Тогда уж нужно просто иметь некие компоненты которые по делают морду по описанию. Но это ведь не скафолдинг?

Он и есть.

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

VD>>Тогда уж нужно просто иметь некие компоненты которые по делают морду по описанию. Но это ведь не скафолдинг?

L>Он и есть.

Что-то в статьях по Руби и Груви он описывается по другому.

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

L>>Он и есть.

VD>Что-то в статьях по Руби и Груви он описывается по другому.

Про груви не знаю, а в руби именно то, о чем я написал.

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

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

Тогда я ничего не понял. Либо это схема WolfHound с хитрым фронтэндом, который собирает страницу из виртуальных кусков запрашивая их асинхронно либо то, что MVC умеет из коробки.

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

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

В чем идея-то? Макро для генерации рест методов сделать для контроллера? Вобщем-то я собирался. В рельсах это resourses.

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

Допустим вьюха отображает список товаров в интернет магазине. Моделью для нее в текущем MVC будет List<Goods>. Потом в ней же понадобилось отобразить что-то еще, например название магазина. Надо либо создавать класс

[Record]
class GoodsViewModel
{
  [Accessor] def goods : list[Goods];
  [Accessor] def shopCaption : string;
}

вьюха будет иметь тип View<GoodsViewModel>
либо передавать название через нетипизированный хеш ViewData["ShopCaption"] = db.CurrentShop.Caption;

Я же хочу генерить такие классы по использованию. Псевдокод

def model = View.Current.Model(); // это указание для какой вьюхи мы будем генерить модель
model.ShopCaption = db.CurrentShop.Caption; // string
model.Goods = db.Goods.Where(g => g.Category == categoryId).Select(g => new (g.Name, g.Price)).ToList();

VD>Как данные могут служить контроллером и зачем?

Контейнером.

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

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

Вот это зря. Получается, что ты много велосипедов изобретаешь. А я хочу просто решить проблемы вполне себе неплохого MVC.

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

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

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

VD>В чем разница?
это делается так:

('#place').load('/product/10');

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

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

Бррр. Мне точно не нужно таких абстракций. Веб разработчик в любом случае знает DOM.

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

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

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

Да кроме экзоктики так все умеют сериализоваться. Я не понял что такое ИСД кто их будет создавать и их основное назначение.

VD>2. Наличие неких плэйсхолдеров в ДОМ-е и АПИ позволяющее заменять их контент.

Хорошо сделанный и отлично документированный jQuery.

VD>3. АПИ которое позволит нам быстро, просто и качественно преобразовать данные в формате ХМЛ/джейсон в ХТМЛ который будет подставляться в плэйсхолдеры.

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

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

Например кладем в папку вьюх файлик partials.spark, а там методы типа:

<def goodsRow row="Goods">
  <tr><td>$(row.Name)<td>$(row.Price)</tr>
</def>

Нужно только в рест вызове указать format=goodsRow и нам приедет готовый html вместо джейсона. Это позволит практически отказаться от генерации html на клиенте.

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

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

Z>Я же хочу генерить такие классы по использованию. Псевдокод
Z>

Z>def model = View.Current.Model(); // это указание для какой вьюхи мы будем генерить модель
Z>model.ShopCaption = db.CurrentShop.Caption; // string
Z>model.Goods = db.Goods.Where(g => g.Category == categoryId).Select(g => new (g.Name, g.Price)).ToList();
Z>

А если созданием модели занимается отдельный класс, его можно будет как то вернуть из метода?

Имхо, самый простой и гибкий вариант был бы что то типа статически типизированного ExpandoObject.
Явно определяем класс

class UserVM {}

var model = new UserVM();
model<-Test = "test";
model.Test //ok
model.Test1 // compile error

Может в Nemerle уже есть такая фича?

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

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

Z>>Я же хочу генерить такие классы по использованию. Псевдокод
Z>>

Z>>def model = View.Current.Model(); // это указание для какой вьюхи мы будем генерить модель
Z>>model.ShopCaption = db.CurrentShop.Caption; // string
Z>>model.Goods = db.Goods.Where(g => g.Category == categoryId).Select(g => new (g.Name, g.Price)).ToList();
Z>>

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

А какая разница где это будет? Главное чтобы для вьюхи был сгенерирован класс модели. Наврядли удастся конечно сохранить такой именно синтаксис.

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

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

VD>1. Подобную функциональность нужно иметь не только для форм, но и вообщем.

Вобщем главное это удобный механизм получения метаданных.

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

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

Вот только я не очень представляю как это сделать. Путь данных лежит через сторонние библиотеки. Надо бы спросить IT, насколько реально протащить метаинформацию сквозь сложный linq запрос.

Но если это получится это будет реально киллер фичей. Так даже рельсы не умеют, афайк.

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

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

Z>Вот только я не очень представляю как это сделать. Путь данных лежит через сторонние библиотеки. Надо бы спросить IT, насколько реально протащить метаинформацию сквозь сложный linq запрос.

Линк реализован в нашех же макросах (смотри здесь). Так что, думаю, любые пробелмы можно будет решить.

Z>Но если это получится это будет реально киллер фичей. Так даже рельсы не умеют, афайк.

Ну, и хорошо.

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

VD>>Ну, такова суть рельсов. Если ничего не мерял, то можешь просто генерить.
D>А зачем тогда что то вообще генерить, думается мне что должна быть в рельсах поддержка генерации в рантайме.

Как я понял — это такой дизайн.

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

Z>Да кроме экзоктики так все умеют сериализоваться. Я не понял что такое ИСД кто их будет создавать и их основное назначение.

Кто все? Нам нужно конерктеные (свои) объекты сериализовать. А это нужно делать. Само собой ничего не произойдет.

VD>>2. Наличие неких плэйсхолдеров в ДОМ-е и АПИ позволяющее заменять их контент.

Z>Хорошо сделанный и отлично документированный jQuery.

jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Z>Т.е. view engine на клиенте?

Да.

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

Не должно тут быть первой и второй очереди. Движок генерации XML/HTML должен быть удобен, быстр и доступен как на сервере, так и на клиенте. Причем лучше всего если клиентский код можно было бы заранее проеврить на наличие багов при компиляции серверной части.

Z>Например кладем в папку вьюх файлик partials.spark, а там методы типа:

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

Z>

Z><def goodsRow row="Goods">
Z>  <tr><td>$(row.Name)<td>$(row.Price)</tr>
Z></def>
Z>

Z>Нужно только в рест вызове указать format=goodsRow и нам приедет готовый html вместо джейсона. Это позволит практически отказаться от генерации html на клиенте.

Вот это в корне не правильное суждение. Я бы даже сказал нарочито не верный дизайн!

Передавать лчше данные, а не верстку. Есть масса причин по которых не стоит всегда генерировать HTML с сервера.

Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).
Вторая — производительность и загрузка сети.
Третья — гибкость.
Четвертая — метаинформация. В данные мы можем добавить метаинформацию которую можно будет использовать для автоматическое генерации кода проверок на клиенте. В HTML же это будет более затруднительно.

Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

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

Z>>Да кроме экзоктики так все умеют сериализоваться. Я не понял что такое ИСД кто их будет создавать и их основное назначение.

VD>Кто все? Нам нужно конерктеные (свои) объекты сериализовать. А это нужно делать. Само собой ничего не произойдет.

Все что должно идти в джейсон должно иметь довольно простую структуру. Эту простую структуру парсер сам разгрызет рефлекшеном.

VD>>>2. Наличие неких плэйсхолдеров в ДОМ-е и АПИ позволяющее заменять их контент.

Z>>Хорошо сделанный и отлично документированный jQuery.

VD>jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Однако она есть в стандартной поставке MVC, и ее активно используют все мвцшники.

VD>Не должно тут быть первой и второй очереди. Движок генерации XML/HTML должен быть удобен, быстр и доступен как на сервере, так и на клиенте. Причем лучше всего если клиентский код можно было бы заранее проеврить на наличие багов при компиляции серверной части.

Не бывает ничего без очереди. Что-то всегда делается раньше.

Z>>Например кладем в папку вьюх файлик partials.spark, а там методы типа:

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

Согласен. Правда не по причине маломощности спарка, а по причине многомощности макросов и лучшей поддержки студией

VD>Передавать лчше данные, а не верстку. Есть масса причин по которых не стоит всегда генерировать HTML с сервера.

Я же не отказываюсь от передачи данных.

VD>Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).

И? Это будет всего лишь один из форматов рест ответа, по умолчанию вернется json.

VD>Вторая — производительность и загрузка сети.

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

VD>Третья — гибкость.

Гибкость чего?

VD>Четвертая — метаинформация. В данные мы можем добавить метаинформацию которую можно будет использовать для автоматическое генерации кода проверок на клиенте. В HTML же это будет более затруднительно.

И? Нужны будут данные — клиент возьмет данные. Без указания формата будет выдан дефолтный, для ajax запроса это будет json. Вот если по этим данным ему понадобится html, проще взять уже готовый html.

VD>Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

А зачем XML? JSON прекрасно обрабатывается клиентом без какого либо движка.

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

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

Z>Все что должно идти в джейсон должно иметь довольно простую структуру. Эту простую структуру парсер сам разгрызет рефлекшеном.

Похоже ты меня не понимаешь. Я говорю о том, что мы должны сериализовать структуры данных существующие в процессе сервера. Скажем класс или вариант сам собой ни в ХМЛ ни в джейсон не запишется. Для этого нужно написать макру которая это сделает.

VD>>jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Z>Однако она есть в стандартной поставке MVC, и ее активно используют все мвцшники.

Ну, и что? Пусть будет. Ты хочешь чтобы твоей библиотекой было проще пользоваться?

VD>>Не должно тут быть первой и второй очереди. Движок генерации XML/HTML должен быть удобен, быстр и доступен как на сервере, так и на клиенте. Причем лучше всего если клиентский код можно было бы заранее проеврить на наличие багов при компиляции серверной части.

Z>Не бывает ничего без очереди. Что-то всегда делается раньше.

Очередность не важна если запланировано то что нужно. А вот если в процессе реализации на одну из фич забить, то будет плохо.

Z>Согласен. Правда не по причине маломощности спарка, а по причине многомощности макросов и лучшей поддержки студией

Нихай так

. Хотя, уверен, что после реализации данной фичи ты согласишься с моим мнением.

Z>Я же не отказываюсь от передачи данных.

А чем их на клиенте в ХМТЛ превращать? jQuery-ем что ли?

VD>>Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).

Z>И? Это будет всего лишь один из форматов рест ответа, по умолчанию вернется json.

А зачем делать работу дважны? Не важно json или ХМЛ. Главное, чтобы не надо было еще вручную ХТМЛ-версию создавать.

json или ХМЛ должны отдаваться просто указанием некоторого параметра и в любом случае. А вот ХТМЛ только если это запланировал разработчик.

VD>>Вторая — производительность и загрузка сети.

Z>Не думаю, что это может стать узким местом, нет разницы сгенерировать json ответ или html. И кешироваться они будут абсолютно идентично.

А что тут думать то?
1. Объем передаваемых данных больше.
2. Нужно время на создание ХТМЛ-я (который еще может содержать сктипты и вообще быть рыхлым).

Z>А вот гонять по сети библиотеку которая умеет рендерить как сервер придется, даже если этот рендер используется на одной странице.

Библиотеки — это всего лишь текстовые файлы которые на раз кэшируются броузером, в отличии от динамического ХТМЛ-я. Код рендеринга у нас будет выглядеть очень компактно — это же ДСЛ! Так что ты опять не прав.

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

Только прикладной программист должен решать где рендерить ХТМЛ на сервере, или на клиенте. И его решение должно быть обусловлено исключительно соображениями прикладной логики, а не тем, что рендерить ХТМЛ на сервере проще чем на клиенте.

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

VD>>Третья — гибкость.

Z>Гибкость чего?

См. выше.

VD>>Четвертая — метаинформация. В данные мы можем добавить метаинформацию которую можно будет использовать для автоматическое генерации кода проверок на клиенте. В HTML же это будет более затруднительно.

Z>И? Нужны будут данные — клиент возьмет данные. Без указания формата будет выдан дефолтный, для ajax запроса это будет json. Вот если по этим данным ему понадобится html, проще взять уже готовый html.

А как ты будешь json и ХМЛ генерировать? И как ты потом будешь по этому json-у формировать на клиенте ХМТЛ?
Надо думать на шаг (а то и на 10) вперед! Иначе по удобству твоя библиотека не сильно превзойдет оригинальный МВЦ.

VD>>Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

Z>А зачем XML? JSON прекрасно обрабатывается клиентом без какого либо движка.

Да без разницы! XML и JSON — это не более чем формат передачи данных. Главено чтобы потом было чем их обработать. Наш движок (по крайней мере его клиентская версия) должен уметь на входе принять как ХМЛ, так и JSON. И то, и то можно рассматривать как ту самую ИСД.

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

Z>В чем идея-то? Макро для генерации рест методов сделать для контроллера? Вобщем-то я собирался. В рельсах это resourses.

И это тоже. Но главное — иметь четкую и простую логику.

1. Формируем ИСД (думаю, что это нечто похожее на твое ViewModel) с помощью запросов к БД и другим источникам данных.
2. Публикуем ее под некоторым URL. Уже на этом этапе имеем возможность запаивать данные в форматах ХМЛ и JSON.
3. (опционально) Формируем шаблон для преобразования нашей ИСД в ХТМЛ.
4. (опционально) Публикуем под тем же ЮРЛ (или другим) результат преоразования (ХТМЛ). Это позволяет открыть данный ЮРЛ напрямую в браузере.
5. (опционально) Публикуем под тем же ЮРЛ (или другим) сам шаблон. Это позволяет какому-то клиентскому коду получить данные (созданные в п. 2) и сгенерировать по ним ХМТЛ на клиенте (подставив его в некоторый плейсхолдер).

В итоге получаем красивую, простую и ясную схему разработки веб-прилоожения.

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

Z>>Все что должно идти в джейсон должно иметь довольно простую структуру. Эту простую структуру парсер сам разгрызет рефлекшеном.

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

Чем JsonConvert.SerializeObject(объект) хуже макры?

VD>>>jQuery — это скриптовая библиотека не имеющая отношения к нашей библиотеке. Понятно, что если будет нужно, то возьмут jQuery или еще что-то и сделают все вручную. Но хочется ведь по больше автоматики и декларативности. Хочется так, чтобы для большинства простых сценариев можно было бы отбойтись без jQuery.

Z>>Однако она есть в стандартной поставке MVC, и ее активно используют все мвцшники.

VD>Ну, и что? Пусть будет. Ты хочешь чтобы твоей библиотекой было проще пользоваться?

Расскажи про сценарии в которых можно заменить jQuery более удобной вещью, с примерами.

VD>Очередность не важна если запланировано то что нужно. А вот если в процессе реализации на одну из фич забить, то будет плохо.

Я не против запланировать рендер на клиенте, когда все остальное будет работать без нареканий.

Z>>Я же не отказываюсь от передачи данных.

VD>А чем их на клиенте в ХМТЛ превращать? jQuery-ем что ли?

А надо ли? Может они нужны именно в виде данных. Например задать значение готовым контролам.

VD>>>Первая, и самая важная — это возможность использования возвращаемых сервером значений как REST-RPC (REST-подобные веб-сервисы).

Z>>И? Это будет всего лишь один из форматов рест ответа, по умолчанию вернется json.

VD>А зачем делать работу дважны? Не важно json или ХМЛ. Главное, чтобы не надо было еще вручную ХТМЛ-версию создавать.

Почему дважды? Формировать придется один раз.

VD>json или ХМЛ должны отдаваться просто указанием некоторого параметра и в любом случае. А вот ХТМЛ только если это запланировал разработчик.

Z>>Не думаю, что это может стать узким местом, нет разницы сгенерировать json ответ или html. И кешироваться они будут абсолютно идентично.

VD>А что тут думать то?
VD>1. Объем передаваемых данных больше.

Примерно равен, может быть как больше так и меньше.

VD>2. Нужно время на создание ХТМЛ-я (который еще может содержать сктипты и вообще быть рыхлым).

Вот сравни практически идеальные по скорости конечные методы генерации html и json.

def json(product)
{
  $"{'Name':'$(jEscape(product.Name))','Price':$(jEscape(product.Price))}"; 
}
def html(product)
{
  $"<tr><td>$(hEscape(product.Name))<td>$(product.Price)</tr>"; 
}

Нужен лишь html который будет еще одним форматом представления продукта. Будет ли он рыхлым это выбор пользователя.

VD>Библиотеки — это всего лишь текстовые файлы которые на раз кэшируются броузером, в отличии от динамического ХТМЛ-я. Код рендеринга у нас будет выглядеть очень компактно — это же ДСЛ! Так что ты опять не прав.

Давай пример использования, пусть без деталей. Просто пример.

VD>Но тут важны не какие-то отдельные причины, а сам факт не вреного дизайна ориентированного на постоянный рендеринг на сервере.

VD>Только прикладной программист должен решать где рендерить ХТМЛ на сервере, или на клиенте. И его решение должно быть обусловлено исключительно соображениями прикладной логики, а не тем, что рендерить ХТМЛ на сервере проще чем на клиенте.

Тут ты прав, просто я уточнил, что рендер html на клиенте явление не столь частое и в большинстве случаев легко заменятся рендером на сервере. Поэтому и сомневаюсь, что игра стоит свеч, особенно если это начнет накладывать ограничения на удобство серверного рендера (типа эта фича не будет работать на клиенте, значит мы не будем вводить ее и на сервере).

VD>>>Конечно мы всегда сможем сгенерить XML с помощью серверного движка рендеренга, но обрабатывать его на клиенте без наличия аналогичного клиентского движка будет мягко говоря неудобно.

Z>>А зачем XML? JSON прекрасно обрабатывается клиентом без какого либо движка.

VD>Да без разницы! XML и JSON — это не более чем формат передачи данных. Главено чтобы потом было чем их обработать. Наш движок (по крайней мере его клиентская версия) должен уметь на входе принять как ХМЛ, так и JSON. И то, и то можно рассматривать как ту самую ИСД.

jScript умеет обрабатывать Java Script Object Notation, я не понимю зачем его учить обрабатывать еще и тормозной XML, если кому-то понадобится он возьмет готовую либу.

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

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

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

Z>>В чем идея-то? Макро для генерации рест методов сделать для контроллера? Вобщем-то я собирался. В рельсах это resourses.

VD>И это тоже. Но главное — иметь четкую и простую логику.

VD>1. Формируем ИСД (думаю, что это нечто похожее на твое ViewModel) с помощью запросов к БД и другим источникам данных.

Не, не похоже. Она должна использоваться в куче мест. Поэтому ее все же лучше описать руками или взять из базы. Моя ViewModel используется одной view. А формируется в одном или нескольких экшенах.

VD>2. Публикуем ее под некоторым URL. Уже на этом этапе имеем возможность запаивать данные в форматах ХМЛ и JSON.

Я планировал так — в контроллере пишем макрос который генерит рест методы для модели бд. Либо любой другой модели, но тогда придется прописать руками методы CRUD. Так делает макрос ресурсы в рор.

VD>3. (опционально) Формируем шаблон для преобразования нашей ИСД в ХТМЛ.
VD>4. (опционально) Публикуем под тем же ЮРЛ (или другим) результат преоразования (ХТМЛ). Это позволяет открыть данный ЮРЛ напрямую в браузере.
VD>5. (опционально) Публикуем под тем же ЮРЛ (или другим) сам шаблон. Это позволяет какому-то клиентскому коду получить данные (созданные в п. 2) и сгенерировать по ним ХМТЛ на клиенте (подставив его в некоторый плейсхолдер).

Ну да, оно все само получится, не надо будет ничего специально публиковать. Взгляни на рельсовский respond_to

VD>В итоге получаем красивую, простую и ясную схему разработки веб-прилоожения.
A la RoR. Что в общем-то и планируется.

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

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

Z>Чем JsonConvert.SerializeObject(объект) хуже макры?

Лучше задаться вопросом чем он лучше. Кроме того что он есть я больше преимуществ не нахожу.
А недостатков их много:
1. Динамически типизирован (везде object).
2. (по всей видимости) Медленная работа. Он ведь или через рефлексию работает, или (в лучшем случае) генерирует код сериализаци на лету.
3. Не умеет сериализовать варианты.
4. Не выдает сообщений об ошибках во время компиляции проекта.
5. Ничего не знает о метаинформации из наших моделей. Стало быть скорее всего не сможет ее протаскивать в сериализованные объекты.
6. Является внешней зависимостью (ты ведь об этом говоришь?).
7. Не умеет сериализовать объекты в XML.

Z>Расскажи про сценарии в которых можно заменить jQuery более удобной вещью, с примерами.

Примеры гипотетического года?

Ну, представь себе, что в твоем проекте вообще нет яваскрипта. Весь код на Немерле. При этом даже клиентские скрипты статически типизированы и проверяются при компиляции. При этом где-то в коде у тебя есть что-то подобное:

<table id="users" />
<button click="fullUses">Заполнить список пользователей</button>

<script ran-at="client">
def fullUses(users : Users) : Html
{
  def rows = <#
    <tr foreach="users">
      <td>$ShurName</td>
      <td>$FName</td>
      <td>$Age</td>
      <td>$(fillAddress(Address))</td>
    </tr>
    #>;

  user.RowsXml = rows;
}

def fillAddress(address : list[Addres])
<#
  <table when="address.Any()">
    <tr foreach="address">
      <td>$PostalCode</td>
      <td>$Country</td>
      <td>$City</td>
      <td>$Streetname</td>
      <td>$Number</td>
    </tr>
  </table>
#>
</script>

Z>Я не против запланировать рендер на клиенте, когда все остальное будет работать без нареканий.

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

VD>>А чем их на клиенте в ХМТЛ превращать? jQuery-ем что ли?

Z>А надо ли?

Надо. И очень надо. Вот на РСДН и так все ОК с генерацией ХТМЛ-я. А вот динамики явно не хватате. Писать ее на Явасктипте не хочется даже при наличии jQuery.

Z>Может они нужны именно в виде данных. Например задать значение готовым контролам.

Может быть. А может быть, что эти контролы не смогут понять данные в передаваемомо формете. Вообще много чего может быть. Это не конструктивно.

Z>Почему дважды? Формировать придется один раз.

Что и зачем формировать? Я хочу имея описание серверного объекта одним атрибутом получить его в сериализованных в ХМЛ или джейсон данные.

VD>>1. Объем передаваемых данных больше.

Z>Примерно равен, может быть как больше так и меньше.

Это домысли. Он по любому будет больше. Не могут быть данные равны или меньше чем их форматированное представление.
А вот насколько он будет больше зависит от того насколько жирным окажется ХТМЛ.

VD>>2. Нужно время на создание ХТМЛ-я (который еще может содержать сктипты и вообще быть рыхлым).

Z>Вот сравни практически идеальные по скорости конечные методы генерации html и json.
Z>

Z>def json(product)
Z>{
Z>  $"{'Name':'$(jEscape(product.Name))','Price':$(jEscape(product.Price))}"; 
Z>}
Z>def html(product)
Z>{
Z>  $"<tr><td>$(hEscape(product.Name))<td>$(product.Price)</tr>"; 
Z>}
Z>

Это очковтирательство! ХТМЛ не бывает таким плоским. Он по любому будут содержать кучу разной фигнию.
Плсю ты что джейсон тоже хочешь в виде строк, врунчую генерировать?
Вот сранви с кодом который должен быть по моим представлением:

contriller.RegistrUrl(@"/somepage/secondpape", Format.Xml | Format.Json, GetData());

И все! Проблемы преобразования всего этого дела в XML и JSON — это проблема библиотеки. Если нужно будет иметь так же и HTML и/или шаблон, мы добавляем к этому коду еще регистрацию функции производящей преобрзование данных в HTML и/или ссылку на шаблон (который, как мы помним, един как для сервера так и для клиента). Шаблон уж нас ДСЛ-ьные, так что мы можем смело выставлять его в веб. Ничего страшного не случится.

Z>Нужен лишь html который будет еще одним форматом представления продукта. Будет ли он рыхлым это выбор пользователя.

Вот именно "еще одним". И только его и нужно описывать руками. Остальное (т.е. XML и JSON) должно быть декларативно.

VD>>Библиотеки — это всего лишь текстовые файлы которые на раз кэшируются броузером, в отличии от динамического ХТМЛ-я. Код рендеринга у нас будет выглядеть очень компактно — это же ДСЛ! Так что ты опять не прав.

Z>Давай пример использования, пусть без деталей. Просто пример.

Ну, кое что я тебе уже привел. См. выше.

Z>Тут ты прав, просто я уточнил, что рендер html на клиенте явление не столь частое

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

Z>и в большинстве случаев легко заменятся рендером на сервере. Поэтому и сомневаюсь, что игра стоит свеч, особенно если это начнет накладывать ограничения на удобство серверного рендера (типа эта фича не будет работать на клиенте, значит мы не будем вводить ее и на сервере).

Я думаю, что ограничений быть не должно. Разве что серверный будет несколько быстрее в силу того, что его код будет компилируемым и библиотеки лучше.

А свеч оно точно стоит, так как все идет к большей динамики на сайтах.

VD>>Да без разницы! XML и JSON — это не более чем формат передачи данных. Главено чтобы потом было чем их обработать. Наш движок (по крайней мере его клиентская версия) должен уметь на входе принять как ХМЛ, так и JSON. И то, и то можно рассматривать как ту самую ИСД.

Z>jScript умеет обрабатывать Java Script Object Notation, я не понимю зачем его учить обрабатывать еще и тормозной XML, если кому-то понадобится он возьмет готовую либу.

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

Так же я не понимаю зачем писать сложный код на этих скриптах когда можно написать очень понятный кусок кода на дсл-е (рендерера) и получить все что нужно почти без программирования.

ХМЛ же тормозной только в твоем воображении. А так — это всего лишь иерархический формат. Если не обрабатывать его раком, то он очень удобен, быстр и безопасен (в отличии от джйсона, который по факту — код на явасктипте).

И вообще, опять этот странный подход "я не понимаю зачем Х?". Пользователю удобно. Этого объяснения выше крыши.

Пользователь может получить этот самый ХМЛ из каких-то других источников. С того же Яндекса, к примеру. И что мы прикажем ему делать?
Та же фигня будет когда пользователю придется передать ХМЛ куда-то.

Я предлагаю просто в качестве основного ТЗ прописать простую вещь. Мы предоставляем сериализацию объектов в JSON и XML (HTML рассматриваем как разновидность ХМЛ-я).

Причем данная фича идет из коробки. Человек описал ИСД (ViewModel) — все! Нам только остается зарегистрировать это дело по некоторому Url и мы имеем возможность получить JSON или XML. Причем то что нужно человеку определяется подстановкой некоторого параметра к этому самому зарегистрированному Url.

Другими словами — не надо никакой рукопашной генерации XML и JSON. Единственное что можно допустить — это некую трансформацию структуры.

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

ЗЫ

Но это все нужно делать после того как будет решен вопрос с прозрачной поддержкой БД. Как там на этом фронте?

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

Z>Не, не похоже. Она должна использоваться в куче мест. Поэтому ее все же лучше описать руками или взять из базы. Моя ViewModel используется одной view. А формируется в одном или нескольких экшенах.

ОК. Тогда поясни роль ViewModel и вообще опиши ее реализацию (возможности).

VD>>2. Публикуем ее под некоторым URL. Уже на этом этапе имеем возможность запаивать данные в форматах ХМЛ и JSON.

Z>Я планировал так — в контроллере пишем макрос который генерит рест методы для модели бд. Либо любой другой модели, но тогда придется прописать руками методы CRUD.

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

Я откровенно говоря не очень понимаю зачем нужно ограничение "ViewModel используется одной view". Если его снять, то мое понятие ИСД (иерархическая структура данных) будет очень близко к твоему понятию ViewModel — это некий объект или их совокупность которые описывают данные отображаемые/отдаваемые пользователю за один прием. Эдакий слепо данных собираемый из разных источников.

Такую фигню будет очень легко превратить в XML или JSON и не сложно сгенерировать для него HTML.

Z>Так делает макрос ресурсы в рор.

Что и где, простите?

Z>Ну да, оно все само получится, не надо будет ничего специально публиковать. Взгляни на рельсовский respond_to

Ссылка не открывается

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

Можно про это "само" по подробнее?

VD>>В итоге получаем красивую, простую и ясную схему разработки веб-прилоожения.
Z>A la RoR. Что в общем-то и планируется.

О том и речь. Но с прицелом на статическую типизацию и автоматизацию во время компиляции.

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

Z>>Чем JsonConvert.SerializeObject(объект) хуже макры?

VD>Лучше задаться вопросом чем он лучше. Кроме того что он есть я больше преимуществ не нахожу.
VD>А недостатков их много:
VD>1. Динамически типизирован (везде object).
VD>2. (по всей видимости) Медленная работа. Он ведь или через рефлексию работает, или (в лучшем случае) генерирует код сериализаци на лету.
VD>3. Не умеет сериализовать варианты.
VD>4. Не выдает сообщений об ошибках во время компиляции проекта.
VD>5. Ничего не знает о метаинформации из наших моделей. Стало быть скорее всего не сможет ее протаскивать в сериализованные объекты.

Кстати, а макросами можно реализовать глобальную замену использования одного класса на другой?

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

L>Кстати, а макросами можно реализовать глобальную замену использования одного класса на другой?

Можно (хотя наверно не просто будет), но по-моему — это плохая идея.

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

VD>>Лучше задаться вопросом чем он лучше. Кроме того что он есть я больше преимуществ не нахожу.

Z>Это офигительный плюс. У меня очень ограниченные ресурсы.

Тогда можно было бы взять AST.NET (без МВЦ) или PHP у них тоже этот плюс есть.

Z>А как использовать фичи именно яваскрипта которые не умеет Nemerle? Вот у меня довольно сложная логика раскидана по классам, которые в яваскрипте нифига не классы, как мне ее на немерле переводить? Слишком разные языки.

Зачем переводить? Конечно если у тебя что-то уже написано, то переводить это туда-обратно бессмысленно.

Но если ты пишешь новый сайт, то зачем писать на скрипте (при условии наличия альтернативы)?

Что до различий языков, то по большому счету есть только одно большое различие между Немерлом и Явасктиптом — в последнем ООП прототипный. Но имея классический ООП не трудно его переписать в прототипный. Еще не просто будет с матчами и вариантами, но их можно или эмулировать или просто запретить в клиентских скриптах.

Z>А сделать рендер вобщем-то да, можно. Выглядит неплохо.

Не понял. О чем речь?

Z>Я предложу людям что-то удобнее MVC, с надеждой развития во что-то еще более удобное.

Ну, так может быть лучше если это что-то будет сильно удобнее MVC?

Кроме аргумента "это еще написать надо" есть какие-то "против"?

Z>Так данные форматированными передаются, тут идет вопрос какое форматирование жирнее. Жирнее XML сложно придумать.

Еще раз. Это не должно нас заботить. Это проблема прикладного программиста. Те же Рельсы предоставляют оба варианта.

VD>>Это очковтирательство! ХТМЛ не бывает таким плоским. Он по любому будут содержать кучу разной фигнию.

Z>Какой фигни? Всю фигню ему потом клиент навешает, стили, обработчики.

Да те же макросы, стили...

VD>>Вот сранви с кодом который должен быть по моим представлением:
VD>>

VD>>contriller.RegistrUrl(@"/somepage/secondpape", Format.Xml | Format.Json, GetData());
VD>>

Z>Не дело это в контроллере регистрить урл, роутинг уже есть.

Этр уже детали. Важно чтобы для получения данных нужно было сделать минимум работы (оптимально вообще без работы).

Выглядеть должно примерно так.
Z>

Z>def Get(id : Guid)
Z>{
Z>    def model = db.Persons.Single(p => p.Id == id);
Z>    ViewByFormat(model);
Z>}
Z>

Z>Вот и все, вернется то, что запрашивается, это определятется по заголовку Accept в реквесте или по дополнительному полю в запросе. Хтмл форматы будут могут быть описаны в одном view файлике или в одноименных формату файликах, на выбор пользователя.

ОК, так тоже можно. Но кто (что) будет осуществлять эту самую магию ViewByFormat?

Z>Да я не против этого инструмента, но в обозримом будущем не вижу у себя одного ресурсов на его создание.

Ну, может кто-то подключится. За себя не скажу, на мне еще баги в компиляторе и интеграции.

Z>Потому и не хочу сейчас решать что-то про него, эти вопросы я планирую решать после своего роадмапа, он не вносит никаких ограничений архитектурных.

Боюсь, что если спроектировать форматер без учета возможности использования этого дела на клиенте, то потом будте очень сложно их соеденить.

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

Z>Ты видишь задачу только в рендере, а задачи как раз в хитрой динамике, я сейчас делаю онлайн заполнение excel файлов, так там клиентской генерации html на 1% крайне простого кода. Зато дофигища использования всяческих селекторов, переключений стилей, аякс запросов. Все это проще делать на jScript, это его родное занятие, и я не считаю его недоязыком по сравнению с немерлом.

1. Ты же не считаешь, что твой случий единственный. Правда?
2. Если у тебя будет тот самый рендерер и типизированный сктипт, то ты наверно только выиграешь?

Z>На яваскрипте его придется обрабатывать именно раком и он будет тормозить.

Это вопрос библиотек, а не приципиальное ограничение.

VD>>И вообще, опять этот странный подход "я не понимаю зачем Х?". Пользователю удобно. Этого объяснения выше крыши.

Z>Удобно — пусть возьмет готовую либу чтения xml, зачем я ее буду писать?

Ты ему должен предоставить ХМЛ по запросу. Ну, тот самый твой ViewByFormat.
А уж если будет клиентский рендерер, то он тоже должен уметь взять на вход ХМЛ, если что.

Z>Одному там будет нужен xpath, второму превращение в объекты, третьему трансформация. Это не дело для общего фреймворка.

Не, не... не. Мы говорили только о двух вещах. Автоматической генерации ХМЛ-я для (чего-то там вроде ИСД или ViewModel). И локальный рендерер который умет на входе принимать ХМЛ.

Z>Передать как раз не проблема, .net прекрасно работает с XML.

Прои чем тут нет? Я сейчас о клиенте скорее. Потом донет он со всем умеет работать. Но зачем-то ты ведь что-то собрался писать. Все дело в простоте!

Z>Это просто один из хелперных макросов в одном из последних пунктов, зачем на нем циклиться, да еще объявлять основной фичей?

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

VD>>Другими словами — не надо никакой рукопашной генерации XML и JSON. Единственное что можно допустить — это некую трансформацию структуры.

Z>Где я писал про рукопашную генерацию xml или json?

Ну, я тебе (и твои примеры) так понял.

Если твой ViewByFormat будет обеспечивать это, то вопросов больше не имеем.

Z> // сейчас падает тут =) Нужно убивать констрейнты связанные с полем,
Z> // думаю как это красиво сделать
Z> drop Price;

А что за проблема?

Z>Или не надо, ибо часто хочется задать это именно в сиквеле

И это будет приговор тому самому автоматическому развертыванию.

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

Z>>А сделать рендер вобщем-то да, можно. Выглядит неплохо.

VD>Не понял. О чем речь?

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

VD>Ну, так может быть лучше если это что-то будет сильно удобнее MVC?

Со временем станет сильно удобнее

Я за эволюцию.

VD>Кроме аргумента "это еще написать надо" есть какие-то "против"?

Я привел аргументы. Основные это — надо много писать и он может портить жизнь серверному рендеру.

VD>ОК, так тоже можно. Но кто (что) будет осуществлять эту самую магию ViewByFormat?

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

http://api.rubyonrails.org/classes/ActionController/MimeResponds/InstanceMethods.html

Вкратце метод проверяет переданный параметр format и/или хидер Accept в зависимости от них передает управление нужному рендереру, а уж они отдают нужный результат.

VD>Ну, может кто-то подключится. За себя не скажу, на мне еще баги в компиляторе и интеграции.

К тому времени и будет виднее.

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

Вот вот, именно этого я и боюсь, что пытаясь скрестить рендер на клиенте и сервере мы получим неудбоную ни там ни дам диковинку. А так у меня нет форматера в роадмапе. Очень желательно оставить возможность использовать дефолтный asp.net при отказе от небольшого количества фич.

VD>1. Ты же не считаешь, что твой случий единственный. Правда?
VD>2. Если у тебя будет тот самый рендерер и типизированный сктипт, то ты наверно только выиграешь?

Вобщем да. Но это все дело будущего.

Z>>На яваскрипте его придется обрабатывать именно раком и он будет тормозить.

VD>Это вопрос библиотек, а не приципиальное ограничение.

Вот вот, я и хочу отдать выбор бибилотек в руки пользователя.

VD>Ты ему должен предоставить ХМЛ по запросу. Ну, тот самый твой ViewByFormat.
VD>А уж если будет клиентский рендерер, то он тоже должен уметь взять на вход ХМЛ, если что.

Когда будет — не вопрос.

Z>> // сейчас падает тут =) Нужно убивать констрейнты связанные с полем,
Z>> // думаю как это красиво сделать
Z>> drop Price;

VD>А что за проблема?

Да с колонкой связаны констрейнты, она не дропается. А ддл скрипт пока строится без обращения к БД.

Z>>Или не надо, ибо часто хочется задать это именно в сиквеле

VD>И это будет приговор тому самому автоматическому развертыванию.

В смысле? Это будет полуприговор кроссбд приложению, но это не всем нужно, обычно нужна работа со своей конкретной любимой бд, или парочкой. А вообще тулкит должен уметь делать константы, надо только его поковырять на этот счет. Вообще надо бы так:

Id : Guid(pk) = Sql.NewGuid;

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

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

Z>Я согласен с тем, что рендер хтмл на клиенте идея хорошая. Я не отказываюсь от нее полностью.
VD>>Ну, так может быть лучше если это что-то будет сильно удобнее MVC?

Z>Со временем станет сильно удобнее

Я за эволюцию.

ОК

Z>Я привел аргументы. Основные это — надо много писать и он может портить жизнь серверному рендеру.

Про жизнь не понял.

VD>>ОК, так тоже можно. Но кто (что) будет осуществлять эту самую магию ViewByFormat?
Z>Обычный метод, я же давал ссылку, хоть ты и назвал ее нерабочей, но у меня открывается.
Z>http://api.rubyonrails.org/classes/ActionController/MimeResponds/InstanceMethods.html

Сейчас открылась. Видимо первая ссылка была кривая.

Ну, и что мы там видим? У них преобразование в ХМЛ делается за счет динамики. Сам по себе такой метод сособо не нужен, по крайней мере когда речь идет о ХМЛ и Джейсон. Эти форматы нужны всегда. По крайней мере хуже от них не будет.

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

Z>Вкратце метод проверяет переданный параметр format и/или хидер Accept в зависимости от них передает управление нужному рендереру, а уж они отдают нужный результат.

А кто будет писать этот метод? И зачем метод? Не лучше ли атрибуты (мета-татрибуты)?

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

Z>Вот вот, именно этого я и боюсь, что пытаясь скрестить рендер на клиенте и сервере мы получим неудбоную ни там ни дам диковинку.

Мне кажется мы разного боимся.

Z> А так у меня нет форматера в роадмапе. Очень желательно оставить возможность использовать дефолтный asp.net при отказе от небольшого количества фич.

А что в этом хорошего то?

VD>>1. Ты же не считаешь, что твой случай единственный. Правда?
VD>>2. Если у тебя будет тот самый рендерер и типизированный сктипт, то ты наверно только выиграешь?

Z>Вобщем да. Но это все дело будущего.

Будущее не настанет, если он нем не дуать. Точнее настанет другое будущее.

Z>>> // сейчас падает тут =) Нужно убивать констрейнты связанные с полем,
Z>>> // думаю как это красиво сделать
Z>>> drop Price;

VD>>А что за проблема?

Z>Да с колонкой связаны констрейнты, она не дропается. А ддл скрипт пока строится без обращения к БД.

А откуда они берутся?

Z>>>Или не надо, ибо часто хочется задать это именно в сиквеле

VD>>И это будет приговор тому самому автоматическому развертыванию.

Z>В смысле?

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

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

Но это совсем ущербная стратегия так как никакой автоматики при этом не будет. Пользователь вместо "нажал F5 — получил рабочее приложение" будет иметь геморрой с версиями БД.

Z>Это будет полуприговор кроссбд приложению, но это не всем нужно, обычно нужна работа со своей конкретной любимой бд, или парочкой.

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

Z> А вообще тулкит должен уметь делать константы, надо только его поковырять на этот счет. Вообще надо бы так:
Z>

Z>Id : Guid(pk) = Sql.NewGuid;
Z>

Что-то я не понимаю о чем идет речь. Ты вроде бы говорил о правках чего-то в БД...

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

Z>>Я привел аргументы. Основные это — надо много писать и он может портить жизнь серверному рендеру.

VD>Про жизнь не понял.

Любая новая фича серверного движка должна будет иметь реализацию в клиентском. Это будет сильно тормозить ввод новых фич.

VD>Ну, и что мы там видим? У них преобразование в ХМЛ делается за счет динамики. Сам по себе такой метод сособо не нужен, по крайней мере когда речь идет о ХМЛ и Джейсон. Эти форматы нужны всегда. По крайней мере хуже от них не будет.

VD>Так что я бы хотел чтобы вместо подобного метода были просто атрибуты указывающие в каком виде нужны данные. Причем чтобы ХМЛ и Джейсон были доступны по умолчанию, а если они не нужны, чтобы их можно было отключить при помощи атрибутов.

Да мне все равно как будет осуществляться именно преобразование. Я не вижу в этом проблемы фреймворка. Задача фреймворка без лишних движений отдать нужный результат. А какой форматтер его произведет дело не столь важное.

VD>А кто будет писать этот метод? И зачем метод? Не лучше ли атрибуты (мета-татрибуты)?

Узнать, что хочет запросивший обычный код, чем тут помогут атрибуты

.

Z>> А так у меня нет форматера в роадмапе. Очень желательно оставить возможность использовать дефолтный asp.net при отказе от небольшого количества фич.

VD>А что в этом хорошего то?

В возможности иметь привычный рендерер? Кривая обучения глаже. Имеется в виду не отказ от реализации фич, а то, что они не будут работать с aspx view, при этом все остальное будет работать так же.

Z>>Да с колонкой связаны констрейнты, она не дропается. А ддл скрипт пока строится без обращения к БД.

VD>А откуда они берутся?

В данном случае это дефолтное значение.

ALTER TABLE [dbo].[TestTable] ADD  DEFAULT ('10') FOR [Price]

Z>>>>Или не надо, ибо часто хочется задать это именно в сиквеле

VD>Что-то я не понимаю о чем идет речь. Ты вроде бы говорил о правках чего-то в БД...

Задавать дефолтное значение в конструкциях сиквела и править чего-то там в БД разные вещи.

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

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

Z>В данном случае это дефолтное значение.
Z>

Z>ALTER TABLE [dbo].[TestTable] ADD  DEFAULT ('10') FOR [Price]
Z>

Как я понимаю он был создан твоей же миграцией? Значит информация о его существовании у тебя есть и ты можешь сделать дроп этого констрэйна перед измененем поля.

Собственно в моей схеме — жить от модели — такие вещи легко разгуливались, так как модификация БД создавалась как результат сравнения двух моделей. Со сктиптами будет сложнее. Их придется анализировать и фактически создавать по ним виртуальную модель. Но тоже очень даже можно все реализовать.

Z>Задавать дефолтное значение в конструкциях сиквела и править чего-то там в БД разные вещи.

Что то я это не могу понять. Ты говоришь о том, что хочешь подвешивать строки с TSQL-ем вместо метаинформации? А как же тогда будет с поддержкой других серверов? Да и контроль будет на уровне плинтуса.

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

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

Z>>В данном случае это дефолтное значение.
Z>>

Z>>ALTER TABLE [dbo].[TestTable] ADD  DEFAULT ('10') FOR [Price]
Z>>

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

Я могу узнать перед дропом. Это не проблема вобщем-то ) Просто ты спросил о состоянии дел, я ответил, на чем остановился.

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

Зачем? При выполнении есть вполне реальная модель. А до выполнения она не нужна особо.

Z>>Задавать дефолтное значение в конструкциях сиквела и править чего-то там в БД разные вещи.

VD>Что то я это не могу понять. Ты говоришь о том, что хочешь подвешивать строки с TSQL-ем вместо метаинформации? А как же тогда будет с поддержкой других серверов? Да и контроль будет на уровне плинтуса.

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

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

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

Z>Я могу узнать перед дропом. Это не проблема вобщем-то ) Просто ты спросил о состоянии дел, я ответил, на чем остановился.

Можешь конечно. Только для это уже нужно шаблоны SQL-я применять. Иначе дроп твой будет работать только на одном типе СУБД.

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

Кстати, ты думал об этих самых шаблонах?
Для этого я в свое время создал Nemerle.StringTemplate. Он для этого дела отлично подходит.

Z>Зачем? При выполнении есть вполне реальная модель.

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

Z>А до выполнения она не нужна особо.

Тогда до выполнения ты особо ничего и создать не можешь (SQL-скриптов и т.п.).

Z>Рано или поздно кому-то захочется сделать дефолтное значение результатом вызова своей функции и ему не нужна будет поддержка других серверов.

Я вижу что ты какими-то странными оправданиями движешься к весьма мутному дизайну.
Мало ли что там кому рано или поздно надо будет. Если ты будешь вешать строки СУБД-зависимого скрипта на абстратную модель, то у тебя получится не Рельсы, а страшная жуть.

Такие вещи можно делать только через шаблоны. Кому нужно — пусть создает новые шаблоны переопределяя поведение имеющееся по умолчанию.

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

Ну так ты нарвешься на чрезмерную неправильность, что еще хуже.
Если это библиотека предназначена для работы с разными СУБД, то прямого способа зафигачить TSQL или PL-SQL быть не должно.

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

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

Это четкий путь к помойке. Бери пример с умных людей. Для очень похожей задачи создатель ANTLR придумал и реализовал StringTemplate.

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

VD>Можешь конечно. Только для это уже нужно шаблоны SQL-я применять. Иначе дроп твой будет работать только на одном типе СУБД.

Для каждой СУБД нужен будет драйвер. Никуда не денешься. Слишком разные DDL.

VD>А вот если ты их из метаданных вычислишь, то проблем не будет. Хотя если констрэйн создан автоматически сервером, то его имя ты знать не будешь. Так что по любому нужны настраивамемые шаблоны.

VD>Кстати, ты думал об этих самых шаблонах?
VD>Для этого я в свое время создал Nemerle.StringTemplate. Он для этого дела отлично подходит.

Для чего?

Z>>Зачем? При выполнении есть вполне реальная модель.

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

Что значит текущая модель? Модель это база и метаинформация, не надо ничего вычислять, надо только прочитать.

VD>Тогда до выполнения ты особо ничего и создать не можешь (SQL-скриптов и т.п.).

Я совсем запутался, ты себе представляешь, что такое миграции, как ими пользоваться и как вести разработку с их помощью?

VD>Я вижу что ты какими-то странными оправданиями движешься к весьма мутному дизайну.
VD>Мало ли что там кому рано или поздно надо будет. Если ты будешь вешать строки СУБД-зависимого скрипта на абстратную модель, то у тебя получится не Рельсы, а страшная жуть.

Брр... в рельсах это делается не просто, а очень просто. Модель это конкретная БД. У пользователя должны быть все механизмы для получения именно той модели которая ему нужна.

VD>Такие вещи можно делать только через шаблоны. Кому нужно — пусть создает новые шаблоны переопределяя поведение имеющееся по умолчанию.

Какие шаблоны? Как они тут помогут вообще?

VD>Ну так ты нарвешься на чрезмерную неправильность, что еще хуже.
VD>Если это библиотека предназначена для работы с разными СУБД, то прямого способа зафигачить TSQL или PL-SQL быть не должно.

Посмотри на рельсы, гибернейт, тулкит. Они все умеют работать с разными СУБД и во всех можно использовать конкретные возможности конкретной БД. Это лишь привяжет тебя к твоей же базе.

VD>Это четкий путь к помойке. Бери пример с умных людей. Для очень похожей задачи создатель ANTLR придумал и реализовал StringTemplate.

Создатель ANTLR сделал прямое включение кода на используемом языке в грамматику. Это суперудобно. Это то, что я хочу сделать. Если бы он стремился к той правильности о которой ты говоришь, он бы никогда такого не допустил.

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

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

Z>Для каждой СУБД нужен будет драйвер. Никуда не денешься. Слишком разные DDL.

И что твой драйвер будет делать со строками на TSQL?

А драйвер как раз отлично реализовывается через шаблоны. Почти все серверы поддерживают базовый DML (он в стандарте описан), а детали можно легко оформлять через специализации шаблонов.

VD>>Кстати, ты думал об этих самых шаблонах?
VD>>Для этого я в свое время создал Nemerle.StringTemplate. Он для этого дела отлично подходит.

Z>Для чего?

Ты эти свои драйверы будешь для каждой СУБД с нуля вручную клепать? В этих драйверах у тебя будет в основном генерация SQL-я по некоторой модели (общей для всех СУБД).

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

Z>Что значит текущая модель?

Модель поднятая из БД.

Z>Модель это база и метаинформация, не надо ничего вычислять, надо только прочитать.

Вычислять тебе придется то что записано в твоих скриптах. Ты же там императив лепишь. Чтобы из него вычислить модель для конкретной версии нужно или накатить все изменения на БД и прочесть модель из нее, или вычислить эту модель по твоим императивным записям миграций.

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

VD>>Тогда до выполнения ты особо ничего и создать не можешь (SQL-скриптов и т.п.).

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

Да.

VD>>Я вижу что ты какими-то странными оправданиями движешься к весьма мутному дизайну.
VD>>Мало ли что там кому рано или поздно надо будет. Если ты будешь вешать строки СУБД-зависимого скрипта на абстратную модель, то у тебя получится не Рельсы, а страшная жуть.

Z>Брр... в рельсах это делается не просто, а очень просто. Модель это конкретная БД. У пользователя должны быть все механизмы для получения именно той модели которая ему нужна.

Ага. Но там нет возможности вписать SQL-скрпт для конкретной СУБД. Там все делается через свой АПИ. Так что этого минуса у рельсов нет. Их минус — это императивность изменения модели.

VD>>Такие вещи можно делать только через шаблоны. Кому нужно — пусть создает новые шаблоны переопределяя поведение имеющееся по умолчанию.

Z>Какие шаблоны? Как они тут помогут вообще?

Посмотри на примеры которые я тебе давал:
http://nemerle.googlecode.com/svn/nemerle/trunk/ncc/testsuite/positive/string-template-1.n

Если для всех действий создать модель, то эту модель можно преобразовывать в SQL с помощью шаблонов. Шаблоны поддерживают наследование и повторное использование позволяя конкретизировать SQL для конкретных серверов.

VD>>Ну так ты нарвешься на чрезмерную неправильность, что еще хуже.
VD>>Если это библиотека предназначена для работы с разными СУБД, то прямого способа зафигачить TSQL или PL-SQL быть не должно.

Z>Посмотри на рельсы, гибернейт, тулкит.

Сто раз смотрел. И ни где это не поощряется. Везде есть путь написания универсального кода.

Z>Они все умеют работать с разными СУБД

Ага. Но не фигачить голый SQL этих СУБД. Это же очевидная дыра!

Z> и во всех можно использовать конкретные возможности конкретной БД.

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

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

Z>Это лишь привяжет тебя к твоей же базе.

Пока что я вижу, что ты хочешь сделать шаг привязывающий к конекртеной СУБД.

Еще раз повторюсь, что вместо таких шагов нужно вводить шаблоны которые можно будет менять для конекретных СУБД.

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

VD>>Это четкий путь к помойке. Бери пример с умных людей. Для очень похожей задачи создатель ANTLR придумал и реализовал StringTemplate.

Z>Создатель ANTLR сделал прямое включение кода на используемом языке в грамматику.

И это, кстати, ужасно не удобно. Намного удобнее подход принятый в нашем PEG-парсере, где обработчики отделены от грамматики и потенциально (через наследование) могут быть написаны на любом языке.

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

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

Шаблоны отличный способ абстрагироваться от деталей конкретного сервера. Не надо ломать абстракции грязным хаками.

Но, конечно, хозяин — барин.

Z>Это суперудобно.

Да ну? Я вот этого не заметил. Это дико не удобно. Начиная с того, что комплит в этих блоках не работает, и заканчивая тем, что такие блоки резко раздувают объем грамматики и делают ее не читаемой.
Вот посмотри как подобная проблема решается на макросах:
http://nemerle.googlecode.com/svn/nemerle/trunk/snippets/peg-parser/Calculator/CalcParser.n

Так что в этом отношении Антлр сосет. А хорош он именно своим перенастраиваемым кодогенератором.
Так что перенимай положительный опыт, а не отрицательный.

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

Что я могу тут сказать? Делай как считаешь нужным. Это твой проект.
Очень не многие умеют учиться на чужих ошибках. Если ты не из числа, набивай свои шишки. Убеждать тебя до потери пульса я не буду.

Мое мнение ты услышал. Можешь его проигнорировать, а можешь прислушаться. Выбор за тобой.

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

Z>>Для каждой СУБД нужен будет драйвер. Никуда не денешься. Слишком разные DDL.

VD>И что твой драйвер будет делать со строками на TSQL?

Не понял вопроса. Зачем ему что-то делать со строками?

VD>А драйвер как раз отлично реализовывается через шаблоны. Почти все серверы поддерживают базовый DML (он в стандарте описан), а детали можно легко оформлять через специализации шаблонов.

С DML нет проблем, его тулкит делает на ура.

VD>Ты эти свои драйверы будешь для каждой СУБД с нуля вручную клепать? В этих драйверах у тебя будет в основном генерация SQL-я по некоторой модели (общей для всех СУБД).

А темплейты автоматом что ли возникнут?

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

Z>>Что значит текущая модель?

VD>Модель поднятая из БД.

А что тогда новая?

VD>Вычислять тебе придется то что записано в твоих скриптах. Ты же там императив лепишь. Чтобы из него вычислить модель для конкретной версии нужно или накатить все изменения на БД и прочесть модель из нее, или вычислить эту модель по твоим императивным записям миграций.

Именно накатить и прочесть, этого достаточно. Для рельс точно.

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

Я помню что ты предлагал и помню, что предложение дико сырое, непонятно как оно должно вести себя в конфликтных ситуациях.

Z>>Брр... в рельсах это делается не просто, а очень просто. Модель это конкретная БД. У пользователя должны быть все механизмы для получения именно той модели которая ему нужна.

VD>Ага. Но там нет возможности вписать SQL-скрпт для конкретной СУБД. Там все делается через свой АПИ. Так что этого минуса у рельсов нет. Их минус — это императивность изменения модели.

Ты не поверишь

Там есть АПИ и есть возможность. У меня есть АПИ и будет возможность, тут все ок.

VD>>>Такие вещи можно делать только через шаблоны. Кому нужно — пусть создает новые шаблоны переопределяя поведение имеющееся по умолчанию.

Z>>Какие шаблоны? Как они тут помогут вообще?

VD>Посмотри на примеры которые я тебе давал:
VD>http://nemerle.googlecode.com/svn/nemerle/trunk/ncc/testsuite/positive/string-template-1.n

VD>Если для всех действий создать модель, то эту модель можно преобразовывать в SQL с помощью шаблонов. Шаблоны поддерживают наследование и повторное использование позволяя конкретизировать SQL для конкретных серверов.
Плюс еще код, который будет определять какую модель использовать для данного случая. Это и будет драйвер. Т.е. вместо метода:

MakeDdlColumnDrop(table : Table, column : Column)
{
    $"ALTER TABLE $(table.Name) DROP COLUMN $(column.Name)";
}

Придется писать:

MakeDdlColumnDrop(table : Table, column : Column)
{
    RenderTemplate("MSSQL_MakeDdlColumnDrop", table, column);
}

И еще дополнительный шаблон. В чем радость?

Z>>Посмотри на рельсы, гибернейт, тулкит.

VD>Сто раз смотрел. И ни где это не поощряется. Везде есть путь написания универсального кода.

И у меня есть.

Z>>Они все умеют работать с разными СУБД

VD>Ага. Но не фигачить голый SQL этих СУБД. Это же очевидная дыра!

И тут не поверишь

Именно фигачить голый SQL этих СУБД и позволяют.

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

Ну и у меня так же. Ты хаешь непонятно что.

VD>Пока что я вижу, что ты хочешь сделать шаг привязывающий к конекртеной СУБД.

Миграции почти готовы, остались индексы. Давай ты дождешься их описания и потом будешь аргументированно ругать.

Драйвер пока не оформился, я все еще пробую код из януса. У меня сейчас 3 варианта — допиливать код януса, там очень много готового кода, но он на C# и чересчур пухлый, наваять свой используя некоторые возможности тулкита, например по маппингу типов на сиквельные и взять гибернейт, который умеет читать схемы и генерить DDL для всех своих драйверов, но открытого API мне будет недостаточно

. Но драйвер дело внутреннее, его реализация не должна трогать пользователя.

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

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

VD>>И что твой драйвер будет делать со строками на TSQL?

Z>Не понял вопроса. Зачем ему что-то делать со строками?

Ты хотел прицеплять (куда-то) строки конеретного диалекта SQL.

VD>>А драйвер как раз отлично реализовывается через шаблоны. Почти все серверы поддерживают базовый DML (он в стандарте описан), а детали можно легко оформлять через специализации шаблонов.

Z>С DML нет проблем, его тулкит делает на ура.

Это была опечатка. Имелось в виду DDL. Он тоже в большей части весьма стандартен.

VD>>Ты эти свои драйверы будешь для каждой СУБД с нуля вручную клепать? В этих драйверах у тебя будет в основном генерация SQL-я по некоторой модели (общей для всех СУБД).

Z>А темплейты автоматом что ли возникнут?

Нет конечно. Но они позволяют наследовать реализацию и переопределять только то что отличается.
А самое главное, что они позволят прикладному программисту переопределять твою реализауию.

VD>>>>Тогда у тебя получается некий гибридный вариант когда текущая модель есть, а новую нужно вычислять по миграциям. Или заниматься химией вроде "здесь мы играем, а здесь рыбу заворачивали...".
Z>>>Что значит текущая модель?
VD>>Модель поднятая из БД.
Z>А что тогда новая?

Та которую нужно получить.

VD>>Вычислять тебе придется то что записано в твоих скриптах. Ты же там императив лепишь. Чтобы из него вычислить модель для конкретной версии нужно или накатить все изменения на БД и прочесть модель из нее, или вычислить эту модель по твоим императивным записям миграций.

Z>Именно накатить и прочесть, этого достаточно. Для рельс точно.

Вот и получается, что до завешения работы ты ни о чем судить не можешь.
Это минус твоего (и рельсвового) подхода.

Радует только то, что твой императив будет весьма декларативным

.
Его все таки можно будет прочесть и интерпретировать без наличия конкретной СУБД.
Стало быть потенциально можно и "вычислить" модель для некоторой версии.

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

Z>Я помню что ты предлагал и помню, что предложение дико сырое,

Что значит сырое? Точнее будет сказать — не детализированное.

Z>непонятно как оно должно вести себя в конфликтных ситуациях.

На то должен быть составлен ряд решений.

В прочем, тут конечно нет одного true way. У этого подхода тоже есть свои минусы. В некоторых ситуациях придется чем-то пожертвовать или скатиться на тот же императив. Но зато есть и свои плюсы. Один из которых большая автоматизация. Не нужно думать о том как что-то там менять. Просто меняешь модель и получаешь автоматический апгрэйд или даунгрэйд.

VD>>Ага. Но там нет возможности вписать SQL-скрпт для конкретной СУБД. Там все делается через свой АПИ. Так что этого минуса у рельсов нет. Их минус — это императивность изменения модели.

Z>Ты не поверишь

Там есть АПИ и есть возможность. У меня есть АПИ и будет возможность, тут все ок.

Я не видел в рельсах возможности писать сктипты на конеретных диалектах SQL. Но даже если она там есть, то все же по умолчанию предлагается самодостаточное абстрактное АПИ! Это позволяет (грамотным людям желающим поддерживать несколько СУБД) писать код абстрагированный от СУБД. Если ты это обеспечишь, то нет проблем. Если же использование сктиптов уникальных для разных СУБД будет нормой, то это будет плохая система.

VD>>Если для всех действий создать модель, то эту модель можно преобразовывать в SQL с помощью шаблонов. Шаблоны поддерживают наследование и повторное использование позволяя конкретизировать SQL для конкретных серверов.
Z>Плюс еще код, который будет определять какую модель использовать для данного случая.

Вот этот "плюс" это огромный минус! Или ты снова понимаешь под моделью что-то иное чем я.

Z>Это и будет драйвер. Т.е. вместо метода:

Z>

Z>MakeDdlColumnDrop(table : Table, column : Column)
Z>{
Z>    $"ALTER TABLE $(table.Name) DROP COLUMN $(column.Name)";
Z>}
Z>

Z>Придется писать:
Z>

Z>MakeDdlColumnDrop(table : Table, column : Column)
Z>{
Z>    RenderTemplate("MSSQL_MakeDdlColumnDrop", table, column);
Z>}
Z>

Z>И еще дополнительный шаблон. В чем радость?

Второй пример — это какая-то чушь. Радости (в нем) действительно никакой нет.

Если убрать высасанное из пальца требование об использовании разных моделей для разных СУБД, то получается только то, нужно подменять те части шаблона которые требуется. В данном случае у на сбудет по одному TemplateGroup для каждого типа СУБД. В базовом шаблоне будет написано:

[StringTemplateGroup]
class BaseTamplate
{
  ...
  public virtual DropColumn(table : Table, column : Column) {<#
    $"ALTER TABLE $(table.Name) DROP COLUMN $(column.Name)"
  #>}
  ...
}

А, скажем в шаблоне для MS SQL 2008:

[StringTemplateGroup]
class MsSql2008 : BaseTamplate
{
  ...
  public override DropColumn(table : Table, column : Column) {<#
    if exists (select 1 from syscolumns where id = object_id("$(table.Name)") and name = "$(column.Name)")
    begin
        $(base.DropColumn(table, column))
    end
  #>}
  ...
}

или еще что-то.
При этом прикладной программист сможет создать свой StringTemplateGroup и переопределить в нем нужные ему шаблоны для нужной ему СУБД.

Z>>>Посмотри на рельсы, гибернейт, тулкит.

VD>>Сто раз смотрел. И ни где это не поощряется. Везде есть путь написания универсального кода.

Z>И у меня есть.

Если есть, то нет вопросов. Главное чтобы твои хаки не пришлось бы использовать. Вот если не будет другого выхода как прибегнуть к СУБД-зависимому коду, то — это плохо.

Z>>>Они все умеют работать с разными СУБД

VD>>Ага. Но не фигачить голый SQL этих СУБД. Это же очевидная дыра!

Z>И тут не поверишь

Именно фигачить голый SQL этих СУБД и позволяют.

Ага. Не верю!

Точнее верю что есть безграмотные люди которым все по фигу. Но не верю, что нет грамотных.

Z>Ну и у меня так же. Ты хаешь непонятно что.

Ну, а зачем тогда прицеплять СУБД-зависимые строки?

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

ОК

Z>Драйвер пока не оформился, я все еще пробую код из януса. У меня сейчас 3 варианта — допиливать код януса, там очень много готового кода, но он на C# и чересчур пухлый, наваять свой используя некоторые возможности тулкита, например по маппингу типов на сиквельные и взять гибернейт, который умеет читать схемы и генерить DDL для всех своих драйверов, но открытого API мне будет недостаточно

. Но драйвер дело внутреннее, его реализация не должна трогать пользователя.

В Янусе реструктуризация была сделана ужасно плохо. Не стоит равняться на эту реализацию. К тому же в Янусе просто не было тех средств которые есть у тебя.

Еще раз тебе повторяю, что грамотно было бы сделать твои "драйверы" на базе шаблонов и позволить людям знающим детали работы с конкретной СУБД написать драйвер (шаблон) для этих СУБД.

В свое время для януса был написан (на C#) прототип реструктуризатора базировавшегося на StringTemplate (АНТЛР-овском). Даже этот прототип работал в сто раз быстрее и качественнее чем реструктуризатор януса.

Описанные тобой варианты все какие-то кривые. Особенно кривой вариант с хибернэйтом.

Взять мапинг типов из БЛТулкит — идея здравая. Но одним мапингом сыт не будешь.

Меж тем все что тебе нужно сделать — это описать качественную модель (AST) субдэшных абстракций (таблиц, колонок, индексов, констрэйнов...) и весьма прямолинейные шаблоны генерации DDL-я по этим моделям.

Далее тебе нужно буде написать весьма не сложный код генерирующий DDL по твоему DSL.

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

Z>Вот только я не очень представляю как это сделать. Путь данных лежит через сторонние библиотеки. Надо бы спросить IT, насколько реально протащить метаинформацию сквозь сложный linq запрос.

С линком проблем быть не должно. Все метаданные у нас есть. Поддержка лика целиком лежит здесь:
https://nemerle.googlecode.com/svn/nemerle/trunk/Linq

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

VD>Ты хотел прицеплять (куда-то) строки конеретного диалекта SQL.

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

VD>Это была опечатка. Имелось в виду DDL. Он тоже в большей части весьма стандартен.

VD>>>Ты эти свои драйверы будешь для каждой СУБД с нуля вручную клепать? В этих драйверах у тебя будет в основном генерация SQL-я по некоторой модели (общей для всех СУБД).

Z>>А темплейты автоматом что ли возникнут?

VD>Нет конечно. Но они позволяют наследовать реализацию и переопределять только то что отличается.
VD>А самое главное, что они позволят прикладному программисту переопределять твою реализауию.

VD>А, скажем в шаблоне для MS SQL 2008:
VD>[StringTemplateGroup]
VD>class MsSql2008 : BaseTamplate
VD>{
VD> ...
VD> public override DropColumn(table : Table, column : Column) {<#
VD> if exists (select 1 from syscolumns where id = object_id("$(table.Name)") and name = "$(column.Name)")
VD> begin
VD> $(base.DropColumn(table, column))
VD> end
VD> #>}
VD> ...
VD>}
VD>[/c#]
VD>или еще что-то.
VD>При этом прикладной программист сможет создать свой StringTemplateGroup и переопределить в нем нужные ему шаблоны для нужной ему СУБД.

Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.

VD>Если есть, то нет вопросов. Главное чтобы твои хаки не пришлось бы использовать. Вот если не будет другого выхода как прибегнуть к СУБД-зависимому коду, то — это плохо.

Я могу абстрагировать только более менее одинаковые вещи для разных СУБД. Например хранимки, триггеры, спец индексы, вьюхи придется писать на нужном диалекте. Отличие у них не в синтаксисе.

Z>>>>Они все умеют работать с разными СУБД

VD>Ну, а зачем тогда прицеплять СУБД-зависимые строки?

См выше.

VD>В Янусе реструктуризация была сделана ужасно плохо. Не стоит равняться на эту реализацию. К тому же в Янусе просто не было тех средств которые есть у тебя.

VD>Еще раз тебе повторяю, что грамотно было бы сделать твои "драйверы" на базе шаблонов и позволить людям знающим детали работы с конкретной СУБД написать драйвер (шаблон) для этих СУБД.

VD>В свое время для януса был написан (на C#) прототип реструктуризатора базировавшегося на StringTemplate (АНТЛР-овском). Даже этот прототип работал в сто раз быстрее и качественнее чем реструктуризатор януса.

А можно его увидеть? Я сомневаюсь, что заменив String.Format на StringTemplate мы получим что-то сильно качественнее или быстрее.

VD>Меж тем все что тебе нужно сделать — это описать качественную модель (AST) субдэшных абстракций (таблиц, колонок, индексов, констрэйнов...) и весьма прямолинейные шаблоны генерации DDL-я по этим моделям.

VD>Далее тебе нужно буде написать весьма не сложный код генерирующий DDL по твоему DSL.

Это все есть.

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

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

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

Z>Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.

$-строки:
1. Не позволяют изменять реализацию наследованием.
2. Менее эффективны (не рассчитаны на потоковый вывод).
3. Не поддерживают того самого наследования.
4. Не обеспечивают отслеживание отступов. Посмотри на вывод тестов. Там любая вложенная конструкция качественно "отбита" в соответствии со своим уровнем вложенности.

В общем, если ты будешь пытаться реализовать тоже самое на $-строках, то будешь изобретать свой велосипед.

Z>Я могу абстрагировать только более менее одинаковые вещи для разных СУБД. Например хранимки, триггеры, спец индексы, вьюхи придется писать на нужном диалекте. Отличие у них не в синтаксисе.

В рельсах мне не приходится писать на конкретных диалектах SQL. Если у тебя это потребуется, то это уже явный недостаток.

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

Но если даже нужно дать возможность писать код на диалекте SQL, то опять же нужно предоставить прикладным программистам возможность абстрагироваться от конкретных СУБД. Опять же идея сменных шаблонов тут будет рулить.

За одно стоит посмотреть на чужой опыт. Например, в ERWin еще в начале десятиления были макросы которые (не путать их с немерлоыми) позволяли полностью абстрагироваться от деталей реализации СУБД. При этом там поддерживались и треггеры, и представления, и даже хранимые процедуры (хотя последнее не очень впечатляло).

VD>>В свое время для януса был написан (на C#) прототип реструктуризатора базировавшегося на StringTemplate (АНТЛР-овском). Даже этот прототип работал в сто раз быстрее и качественнее чем реструктуризатор януса.

Z>А можно его увидеть? Я сомневаюсь, что заменив String.Format на StringTemplate мы получим что-то сильно качественнее или быстрее.

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

VD>>Далее тебе нужно буде написать весьма не сложный код генерирующий DDL по твоему DSL.

Z>Это все есть.

Где можно посмотреть?

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

VD>Повторять 25 раз, что для этого в грамотном решении используют шаблону я уже устал.
VD>Делай как хочешь. Тебе указали на ошибки. Тебе решать проигнорировать замечания или принять к сведению.

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

Z>>Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.

VD>$-строки:
VD>1. Не позволяют изменять реализацию наследованием.

$(base.DropColumn(table, column)) нельзя написать?

VD>2. Менее эффективны (не рассчитаны на потоковый вывод).

Формируется команда и отдается серверу на исполнение. Зачем здесь применять потоковый вывод

VD>3. Не поддерживают того самого наследования.

Понял не больше чем первый пункт.

VD>4. Не обеспечивают отслеживание отступов. Посмотри на вывод тестов. Там любая вложенная конструкция качественно "отбита" в соответствии со своим уровнем вложенности.

Сервер переживет код без отступов.

VD>В общем, если ты будешь пытаться реализовать тоже самое на $-строках, то будешь изобретать свой велосипед.

Что реализовать-то? Объясни нормально.

VD>В рельсах мне не приходится писать на конкретных диалектах SQL. Если у тебя это потребуется, то это уже явный недостаток.

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

Глупо брать библиотеку не убедившись в том, что эти хранимки не станут проблемой при оптимизации.

VD>Но если даже нужно дать возможность писать код на диалекте SQL, то опять же нужно предоставить прикладным программистам возможность абстрагироваться от конкретных СУБД. Опять же идея сменных шаблонов тут будет рулить.

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

Z>>Это все есть.

VD>Где можно посмотреть?

на гуглкоде. В проекте NRails.Demo есть файлик migrate.cmd, правда он еще не умеет компилить миграции, NRails.Demo.Migrations надо сбилдить руками.

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

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

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

То что ты аргументы игнорируешь не значит, что их не было.

Z>>>Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.

VD>>$-строки:
VD>>1. Не позволяют изменять реализацию наследованием.

Z>$(base.DropColumn(table, column)) нельзя написать?

Написать то конечно можно, только это будет не тоже самое, что подмена реализации шаблона.

VD>>2. Менее эффективны (не рассчитаны на потоковый вывод).

Z>Формируется команда и отдается серверу на исполнение. Зачем здесь применять потоковый вывод

Не потоковый вывод, а потоковую модель формирования конечных строк. StringTemplate создан на одной базе с $-строками. Разница только в том, что он работает значительно быстрее (на больших строках) и гибче.
Грубо говоря весь StringTemplateGrup фомрирует строку в едином StringBuilder в то время как $-строки используют конкатенацию строк. В общем, StringTemplate рассчитан на большие динамические строки, а $-строка на относительно маленькие и формируемые из относительно небольшого числа элементов.

VD>>4. Не обеспечивают отслеживание отступов. Посмотри на вывод тестов. Там любая вложенная конструкция качественно "отбита" в соответствии со своим уровнем вложенности.

Z>Сервер переживет код без отступов.

Сервер то без сомнений переживет. Люди не переживут! Это ведь не просто SQL-скрипт. Это код динамически формируемый по шаблонам. Его ведь еще отлаживать надо. Иногда придется тем же SqlProfiler воспользоваться или просто в логи заглянуть. А там будет ужасно сваленный в кучу текст, вместо хорошо отформатированного SQL-кода.

Ну, да похоже это для тебя тоже не аргумент.

VD>>В общем, если ты будешь пытаться реализовать тоже самое на $-строках, то будешь изобретать свой велосипед.

Z>Что реализовать-то? Объясни нормально.

Да все что перечислено. В прочем это все для тебя не аргументы.
Есть две категории людей. Первая учится на своих и чужих ошибках. Вторая только на чужих. Вот ты похоже из второй категории. Переубедить тебя видимо не получится. Так что набивай свои шишки.

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

Z>Глупо брать библиотеку не убедившись в том, что эти хранимки не станут проблемой при оптимизации.

Если эти хранимки придется писать только для оптимизации, то это куда не шло. Оптимизация нужна 2-3 раза на проект. А вот если это будет штатным трахом, то я бы такую библиотеку не стал испльзовать.

Z>Идею ты так и не озвучил нормально. Давай для тупых, расскажи как ты это видишь.

Вообще-то я уже рассказывал...
Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.
В таких шаблонах можно будет использовать конкретный синтаксис конкретной СУБД. В том числе можно будет делать проверки наличия констрэйнов и удалять их если нужно (что актуально для MS SQL).

Далее в реальных проектах используем не прямой вызов группы шаблонов, а динамическую его загрузку (например, на базе фабрики классов). В реальном проекте прописываем имя (в виде атрибута, например) и загружаем указанную группу. Это позволяет пользователю подсунуть свою группу унаследованную от базовой (или одного из его потомков) и переопределяющий те или иные шаблоны, что позволяет адаптировать генерируемый миграциями код под собственные нужды, но при этом не создавать решение для одной СУБД просто "потому что это проще".

Z>

на гуглкоде. В проекте NRails.Demo есть файлик migrate.cmd, правда он еще не умеет компилить миграции, NRails.Demo.Migrations надо сбилдить руками.

Проще было дать ссылку на файл.

Я что-то там посмотрел, но вместо красивого ДСЛ-я увидил какую-то кучу вложенных лямбд. Это оно?
Если — да, то что с ДСЛ-ем?

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

VD>То что ты аргументы игнорируешь не значит, что их не было.

Я по каждому коментарий написал.

Z>>>>Продолжаю не понимать смысла притягивания в проект StringTemplate. Все что ты продемонстрировал делается с помощью $"" точно так же.

VD>>>$-строки:
VD>>>1. Не позволяют изменять реализацию наследованием.

Z>>$(base.DropColumn(table, column)) нельзя написать?

VD>Написать то конечно можно, только это будет не тоже самое, что подмена реализации шаблона.

Тогда объясни как выглядит подмена реализации шаблона, если это не наследование

VD>>>2. Менее эффективны (не рассчитаны на потоковый вывод).

Z>>Формируется команда и отдается серверу на исполнение. Зачем здесь применять потоковый вывод

VD>Не потоковый вывод, а потоковую модель формирования конечных строк. StringTemplate создан на одной базе с $-строками. Разница только в том, что он работает значительно быстрее (на больших строках) и гибче.
VD>Грубо говоря весь StringTemplateGrup фомрирует строку в едином StringBuilder в то время как $-строки используют конкатенацию строк. В общем, StringTemplate рассчитан на большие динамические строки, а $-строка на относительно маленькие и формируемые из относительно небольшого числа элементов.

Даже если я буду посимвольно складывать этот шаблон, это будет незаметно на фоне выполнения этого запроса. Там на порядки разные сложности. Хреновый аргумент.

VD>>>4. Не обеспечивают отслеживание отступов. Посмотри на вывод тестов. Там любая вложенная конструкция качественно "отбита" в соответствии со своим уровнем вложенности.

Z>>Сервер переживет код без отступов.

VD>Сервер то без сомнений переживет. Люди не переживут! Это ведь не просто SQL-скрипт. Это код динамически формируемый по шаблонам. Его ведь еще отлаживать надо. Иногда придется тем же SqlProfiler воспользоваться или просто в логи заглянуть. А там будет ужасно сваленный в кучу текст, вместо хорошо отформатированного SQL-кода.

VD>Ну, да похоже это для тебя тоже не аргумент.

У меня вполне читаемый sql получается. Конечно не идеально отформатированный, но для чтения человеком вполне достаточно.

VD>Да все что перечислено. В прочем это все для тебя не аргументы.
VD>Есть две категории людей. Первая учится на своих и чужих ошибках. Вторая только на чужих. Вот ты похоже из второй категории. Переубедить тебя видимо не получится. Так что набивай свои шишки.

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

Z>>Идею ты так и не озвучил нормально. Давай для тупых, расскажи как ты это видишь.

VD>Вообще-то я уже рассказывал...
VD>Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.

Наконец что-то более менее понятное. Где доки по всему этому?

VD>В таких шаблонах можно будет использовать конкретный синтаксис конкретной СУБД. В том числе можно будет делать проверки наличия констрэйнов и удалять их если нужно (что актуально для MS SQL).

Пока не очень акутально. Констрейнты тоже входят в модель схемы, проверки лучше делать в ней.

VD>Проще было дать ссылку на файл.

http://code.google.com/p/nemerleonrails/source/browse/Demo/NRails.Demo.Migrations/TestMigration.n
http://code.google.com/p/nemerleonrails/source/browse/NRails.Tests/Migrations/MigrationTests.n

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

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

Z>Тогда объясни как выглядит подмена реализации шаблона, если это не наследование

Я же пример пример (здесь).

[StringTemplateGroup]
class BaseTamplate
{
  ...
  public virtual DropColumn(table : Table, column : Column) {<#
    $"ALTER TABLE $(table.Name) DROP COLUMN $(column.Name)"
  #>}
  ...
}

А, скажем в шаблоне для MS SQL 2008:

[StringTemplateGroup]
class MsSql2008 : BaseTamplate
{
  ...
  public override DropColumn(table : Table, column : Column) {<#
    if exists (select 1 from syscolumns where id = object_id("$(table.Name)") and name = "$(column.Name)")
    begin
        $(base.DropColumn(table, column))
    end
  #>}
  ...
}

или еще что-то.

главное здесь не вызов "base.DropColumn(table, column)" (без него можно обойтись).
Главное здесь, то что шаблон (то что выглядит как функция) переопределяет (override, выделено жирным) шаблон объявленный в базовой группе шаблонов.

Пользователь может заменить этот шаблон, но не может налепить черти чего.

Z>Даже если я буду посимвольно складывать этот шаблон, это будет незаметно на фоне выполнения этого запроса. Там на порядки разные сложности. Хреновый аргумент.

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

С применением $-строк конечно такого не произойдет (точнее получить экспоненту будет сложно, но можно), но зачем же намеренно выбирать худший путь?

Z>У меня вполне читаемый sql получается. Конечно не идеально отформатированный, но для чтения человеком вполне достаточно.

Читаемый без отступов? У нас видимо диаметрально противоположенные понятия о читаемости.

А зачем не идеальный, когда можно получить идеально отформатированный код?

В общем, "упорству храбрых поем мы песню...". Через зад но по-своему.

Z>Да нет, аргументы подкачали.

На мой взгляд, тех что есть выше крыши. У меня нет задачи убедить тебя во что-бы то ни стало.

Z>По крайней мере те, которые я смог понять.

Если ты не понимаешь сказанного, то хорошо бы задуматься над тем почему это происходит. Возможно тебе плохо объясняют. Тогда стоит уточнить детали. А возможно дело в тебе. Если стараться не понять, то точно не поймешь.

Z>Кидаться переписывать драйвер БД изза них я не буду.

У... В нашем деле — это никудышная позиция. Я порой переписываю код по 5 раз только для того чтобы удовлетворить свое чувство прекрасного. Ты делаешь то, что до тебя никто не делал, так что эксперименты — это главный способ выбора лучших решений.

Ведь у тебя еще не готовы драйверы для всех поддерживаемых БЛТулкитом СУБД?

Найти в коде проекта код связанный с драйверами было очень не просто.

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

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

Кстати, зачем было выбирать Меркури в качестве сорс-контрола? У меня на машине даже нечем скачать код.
Пришлось тратить время на поиск и установку клиента.
SVN вроде бы вполне приемлем для открытых проектов и его криент есть почти у всех. Тем самым ты сужаешь аудиторию.

Z>У текущего драйвера есть большой плюс, он дернут из януса и оттуда же можно дернуть для других БД.

Я бы сказал — это большой минус. Основные жалобы на янус всегда были связаны именно с реструктуризатором. К тому же он вроде бы не понимает всех СУБД которые знакомы БЛТулкиту.

Z>Написать с нуля и протестировать темплейты для всех БД я один не в состоянии.

Снова в качестве аргумента минимизация работы? С этого надо было начинать. Тогда хотя бы было понятно откуда такое упорство.

VD>>Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.

Z>Наконец что-то более менее понятное.

Я уже раза три это весе рассказал на разные лады.

Z>Где доки по всему этому?

К сожалению док нет. Но разница с $-строками там очень небольшая. Плюс из трех примеров (string-template-1.n, string-template-2.n, string-template-3.n, ) вся функциональность ясна.

Это не какой-то бином ньютона, а просто специализированная версия $-строк.

Собственно $-строки и StringTemplate имеют общую базу. Поддержка ..$() (то есть работы с коллекциями) в $-строках как раз появилась в процессе работы над StringTemplate.

VD>>В таких шаблонах можно будет использовать конкретный синтаксис конкретной СУБД. В том числе можно будет делать проверки наличия констрэйнов и удалять их если нужно (что актуально для MS SQL).

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

Не так давно, ты утверждал, что проверки очень нужды

. Ну, да пока не надо — это тоже никудышный аргумент. Если проект дойдет до серьезного использования, то сложного SQL-я будет выше крыши.

VD>>Проще было дать ссылку на файл.

Z>http://code.google.com/p/nemerleonrails/source/browse/Demo/NRails.Demo.Migrations/TestMigration.n
Z>http://code.google.com/p/nemerleonrails/source/browse/NRails.Tests/Migrations/MigrationTests.n

Вот, а я нашел какой-то файл где кроме самих миграций еще куча какого-то непонятного кода было.

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

Нашел проект реструктуризатора о котором я говорил. Правда он даже не собирается (компонентов не хватает). И не факт, что это самая последняя версия, но поглядеть можно.

Если интересно могу выслать.

Вот код шаблонов генерировавших SQL (DLL).
Базовый шаблон (GeneralTemplate.sql):

group General;

/* Добавляет к имени символы цитирования. Это позвляет именам содержать
 * пробельные символы и пересекаться с ключевыми словами
 */
Quot(name) ::= <<
[$name$]
>>

/*
 * Преобразование значений в литералы.
 */
StringLiteral(value) ::= <<"$value$">>
AnsiStringLiteral(value) ::= <<"$value$">>
DateTimeLiteral(value) ::= <<"$value$">>

/*****************************************************************************/

/* Генерирует выражение создания индексов.
 *    name - имя индекса.
 *    table - имя таблицы для которой требуется осздать индекс.
 *    type - тип индекса. 
 *    unique - определяет должне ли индекс быть уникальным (булево значение).
 *    entries - вхождения индекса (мулти-атрибут). Каждое вхождение содержит 
 *              атрибуты: Column - имя колонки, и IsAscending - определяющий 
 *              направление сотрировки (true для прямого и false для обратного).
 *              Если индекс многоколоночный, то для каждой колнки в entries будет
 *              содержаться отдельная строка.
 */

CreateIndex(name, table, isClustered, isUnique, entries) ::= <<
/* General:CreateIndex */
CREATE $Unique(isUnique)$ $Clustered(isClustered)$ INDEX $Quot(name)$ ON $Quot(table)$
(
  $entries:{ entry | $entry.Column$ $Direction(entry.IsAscending)$}; separator=",\n"$
)
>>

/* Выводит сточку "UNIQUE" если isUnique равен true. */
Unique(isUnique) ::= <<
$if (isUnique)$ UNIQUE $endif$
>>

Clustered(isClustered) ::= <<
$if (isClustered)$ CLUSTERED$endif$
>>


/* Выводит сточку ASC" если isAscending равен true или "DESC" в обратом случае. */
Direction(isAscending) ::=  <<
$if (isAscending)$ASC$else$DESC$endif$
>>

/*****************************************************************************/

/* Генерирует выражение удаления индекса.
 * name - имя индекса полдежащего удалению.
 * table - имя таблицы индекс которой требуется удалить.
 */
DropIndex(name, table) ::= <<
/* General:DropIndex */
DROP INDEX $Quot(name)$ ON $Quot(table)$
>>

/*****************************************************************************/

/* Добавление колонки.
 * column - Описание колонки:
 * "column.{Name, Type, Nullable, Size, Default, IsVariableSize, IsAutoIncrement}"
 */
 /*TODO: Разобраться с "Nullable"! */
CreateColumn(column, table) ::= <<
/* General:CreateColumn */
ALTER TABLE $Quot(table)$ ADD $ColumnDefinition(column)$
>>

/* "column.{Name, Type, Nullable, Size, Default, IsVariableSize, IsAutoIncrement}" */
ColumnDefinition(column) ::= <<
$column.Name$ $if (column.IsAutoIncrement)$INTEGER$Nullable(column)$ IDENTITY$else$$TypeDef(column)$$endif$
>>

TypeDef(column) ::= <<
    $Type(column)$$Nullable(column)$$column.Default:Default()$
>>

Nullable(column) ::= <<
$if (column.Nullable)$ NULL$else$ NOT NULL$endif$
>>

/* "column.{Name, Type, Nullable, Size, Default, IsVariableSize, IsAutoIncrement}" */
Type(column) ::= <<
    $column.Type$$if (column.IsVariableSize)$($column.Size$)$endif$
>>

Default(value) ::= <<
 DEFAULT $value$
>>

/*****************************************************************************/

/* A column cannot be dropped when it is (MS SQL): 
    * Used in an index.
  * Used in a CHECK, FOREIGN KEY, UNIQUE, or PRIMARY KEY constraint.
  * Associated with a default that is defined with the DEFAULT keyword, or 
    bound to a default object.
  * Bound to a rule. 
*/

DropColumn(name, table) ::= <<
/* General:DropColumn */
$DropColumnDefault(table=table, columnName=name)$
ALTER TABLE $Quot(table)$ DROP COLUMN $Quot(name)$
>>

/*****************************************************************************/

CreateTable(name, columns) ::= <<
/* General:CreateTable */
CREATE TABLE $Quot(name)$
(
  $columns:ColumnDefinition(); separator=",\n"$
)
>>

/*****************************************************************************/

DropTable(name) ::= <<
/* General:DropTable */
DROP TABLE $Quot(name)$
>>


/*****************************************************************************/
/* table - Имя таблицы у которой изменена колонка.
 * Параметры isXxxChanged имеют тип bool и собщают о том был ли изменено
 * то или иное свойство колнки.
 * 
 * У параметров modelColumn и targetColumn имеются следующие свойства:
 *  Name, Type, Size, Nullable, Default, IsVariableSize, IsAutoIncrement
*/
AlterColumn(table,
    isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
    isAutoIncrementChanged,
    modelColumn, targetColumn) ::= 
<<
/* General:AlterColumn */
    $!Print_AlterColumn(table=table, isDataTypeChanged=isDataTypeChanged, 
        isDefaultChanged=isDefaultChanged, isNullableChanged=isNullableChanged, 
        isSizeChanged=isSizeChanged, isAutoIncrementChanged=isAutoIncrementChanged,
        modelColumn=modelColumn, targetColumn=targetColumn)!$

$if (isDefaultChanged)$
    $if (modelColumn.Default)$
        $AddColumnDefault(table=table, column=modelColumn)$
    $else$
        $DropColumnDefault(table=table, columnName=targetColumn.Name)$
    $endif$
$endif$
    
$if (isNullableChanged)$$if (!modelColumn.Nullable)$
$MakeUpdate(table=table, modelColumn=modelColumn)$

$endif$$endif$
    $if (isDataTypeChanged)$
ALTER TABLE $Quot(table)$ ALTER COLUMN $Quot(targetColumn.Name)$ 
        $Type(modelColumn)$ $Nullable(modelColumn)$ /* isDataTypeChanged */
    $else$
        $if (isNullableChanged)$
ALTER TABLE $Quot(table)$ ALTER COLUMN $Quot(targetColumn.Name)$ 
        $Type(modelColumn)$ $Nullable(modelColumn)$ /* isNullableChanged */
        $endif$
    $endif$
>>

MakeUpdate(table, modelColumn) ::= <<
/* General:MakeUpdate modelColumn.Default:$modelColumn.Default$ */
$if (modelColumn.Default)$
UPDATE $Quot(table)$
    SET $Quot(modelColumn.Name)$ = $modelColumn.Default$ /* $modelColumn.CliType$ */
    WHERE $Quot(modelColumn.Name)$ IS NULL
$else$
UPDATE $Quot(table)$
    SET $Quot(modelColumn.Name)$ = $DefaultValueForType.(modelColumn.CliType)$ /* $modelColumn.CliType$ */
    WHERE $Quot(modelColumn.Name)$ IS NULL
$endif$

go
>>

DefaultValueForType ::= 
[
    "AnsiString"    : "''",
    "AnsiStringLob" : "''",
    "StringLob"     : "''",
    "String"        : "''",
    "default"       : "0"
]

AlterColumnSetAutoIncrement(table,
    isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
    isAutoIncrementChanged,
    modelColumn, targetColumn) ::= 
<<
/* General:AlterColumnSetAutoIncrement */
ALTER TABLE $Quot(table)$ DROP COLUMN $Quot(targetColumn.Name)$  
go
ALTER TABLE $Quot(table)$ ADD $Quot(modelColumn.Name)$ INTEGER IDENTITY NOT NULL
go
>>

AlterColumnRemoveAutoIncrement(table,
    isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
    isAutoIncrementChanged,
    modelColumn, targetColumn) ::= 
<<

Внимание, эта операция специяична для СУБД!
Создайте ее реализацию в специализированном шаблоне!

>>

Print_AlterColumn(table,
    isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
    isAutoIncrementChanged,
    modelColumn, targetColumn) ::= 
<<
    /*
    table                        = '$table$'
    isDataTypeChanged            = '$isDataTypeChanged$'
    isDefaultChanged             = '$isDefaultChanged$'
    isNullableChanged            = '$isNullableChanged$'
    isSizeChanged                = '$isSizeChanged$'
    isAutoIncrementChanged       = '$isAutoIncrementChanged$'
    
    modelColumn.Name             = '$modelColumn.Name$'
    modelColumn.Type             = '$modelColumn.Type$'
    modelColumn.Size             = '$modelColumn.Size$'
    modelColumn.Nullable         = '$modelColumn.Nullable$'
    modelColumn.Default          = '$modelColumn.Default$'
    modelColumn.IsVariableSize   = '$modelColumn.IsVariableSize$'
    modelColumn.IsAutoIncrement  = '$modelColumn.IsAutoIncrement$'
    
    targetColumn.Name            = '$targetColumn.Name$'
    targetColumn.Type            = '$targetColumn.Type$'
    targetColumn.Size            = '$targetColumn.Size$'
    targetColumn.Nullable        = '$targetColumn.Nullable$'
    targetColumn.Default         = '$targetColumn.Default$'
    targetColumn.IsVariableSize  = '$targetColumn.IsVariableSize$'
    targetColumn.IsAutoIncrement = '$targetColumn.IsAutoIncrement$'
    */
>>

/*****************************************************************************/

MsSqlServerTemplate.sql:

group MsSqlServer;

/*
 * Преобразование значений в литералы.
 */
StringLiteral(value) ::= <<N'$value$'>>
AnsiStringLiteral(value) ::= <<'$value$'>>
DateTimeLiteral(value) ::= <<'$value$'>>

/*****************************************************************************/

AlterColumnRemoveAutoIncrement(table,
    isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
    isAutoIncrementChanged,
    modelColumn, targetColumn) ::= 
<<
/* MsSqlServer:AlterColumnRemoveAutoIncrement */
EXEC sp_rename '$table$.$targetColumn.Name$', '$targetColumn.Name$_tmp', 'COLUMN'
go
ALTER TABLE $Quot(table)$ ADD $Quot(modelColumn.Name)$ $Type(modelColumn)$ $modelColumn.Default:Default()$
go
UPDATE $Quot(table)$ SET $Quot(modelColumn.Name)$ = $Quot(modelColumn.Name + "_tmp")$
go
$if (modelColumn.Nullable)$
    ALTER TABLE $Quot(table)$ ALTER COLUMN $NameTypeAndNullable(modelColumn)$
go
$endif$
ALTER TABLE $Quot(table)$ DROP COLUMN  $Quot(modelColumn.Name + "_tmp")$
>>

NameTypeAndNullable(column) ::= <<
$Quot(column.Name)$ $Type(column)$$Nullable(column)$
>>

/*****************************************************************************/

AddColumnDefault(table, column) ::= 
<<
$DropColumnDefault(table=table, columnName=column.Name)$
go
ALTER TABLE $Quot(table)$ 
    ADD CONSTRAINT $Quot("DefConstr" + table + column.Name)$
        DEFAULT $column.Default$ FOR $Quot(column.Name)$
>>

/*****************************************************************************/

DropColumnDefault(table, columnName) ::= 
<<
/* MsSqlServer:DropColumnDefault */
/* Если у колонки существует знчение по умолчанию... */

IF Exists(SELECT *
        FROM sys.all_columns as cols INNER JOIN sys.default_constraints 
          ON cols.default_object_id = sys.default_constraints.object_id
        WHERE cols.object_id = OBJECT_ID('$table$')
                AND cols.name = '$columnName$')
BEGIN
    DECLARE @constraintName SYSNAME
    /* Определяем его имя */
    SELECT @constraintName = sys.default_constraints.name
        FROM sys.all_columns as cols INNER JOIN sys.default_constraints 
          ON cols.default_object_id = sys.default_constraints.object_id
        WHERE cols.object_id = OBJECT_ID('$table$')
                AND cols.name = '$columnName$'
  /* Удаляем ограничение. */
    EXEC('ALTER TABLE $Quot(table)$ DROP CONSTRAINT [' + @constraintName + ']');
    /*PRINT 'Огнаничение ' + @constraintName + ' удалено!'*/
END
>>

MsJetTemplate.sql:

group MsJet;

AlterColumnRemoveAutoIncrement(table,
    isDataTypeChanged, isDefaultChanged, isNullableChanged, isSizeChanged,
    isAutoIncrementChanged,
    modelColumn, targetColumn) ::= 
<<
/* MsJet:AlterColumnRemoveAutoIncrement */
$AlterColumn(table=table, isDataTypeChanged=isDataTypeChanged, 
    isDefaultChanged=isDefaultChanged, isNullableChanged=isNullableChanged, 
    isSizeChanged=isSizeChanged, isAutoIncrementChanged=isAutoIncrementChanged,
    modelColumn=modelColumn, targetColumn=targetColumn)$

>>

/*****************************************************************************/

AddColumnDefault(table, column) ::= 
<<
/* MsJet:AddColumnDefault */
ALTER TABLE $Quot(table)$ 
    ALTER COLUMN $Quot(column.Name)$ SET DEFAULT $column.Default$;
go
UPDATE $Quot(table)$ 
    SET $Quot(column.Name)$ = $column.Default$
    WHERE $Quot(column.Name)$ IS NULL
go
>>

/*****************************************************************************/

DropColumnDefault(table, columnName) ::= 
<<
/* MsJet:DropColumnDefault */
ALTER TABLE $Quot(table)$ ALTER COLUMN $Quot(columnName)$ DROP DEFAULT;
>>

/*****************************************************************************/

Clustered(isClustered) ::= <<
/* CLUSTERED */
>>

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

Попробовал собрать солюшен.

Проект NRails.Demo валится:
Doctor.n(8,6):Error: Doctor model error: System.Data.SqlClient.SqlException: Cannot open database "NRailsDemo" requested by the login. The login failed.

Попробовал создать БД с помощью VS (у меня MS SQL Express поставленный 2010-ой студией), но она выдает сообщение об ошибке при попытке проверить соединение выдает:

---------------------------
Microsoft Visual Studio
---------------------------
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 — Could not open a connection to SQL Server)
---------------------------
ОК
---------------------------

Утилит к экспрессу никаких нет, так что не ясно что делать.

Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?

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

VD>Попробовал собрать солюшен.

VD>Проект NRails.Demo валится:
VD>Doctor.n(8,6):Error: Doctor model error: System.Data.SqlClient.SqlException: Cannot open database "NRailsDemo" requested by the login. The login failed.

Верно, ему для сборки нужна корректная БД. Для корректной БД нужна собранная NRails.Demo.Migrations и NRails.Console. Надо научиться компилировать миграции в памяти, без msbuild, тогда не нужен будет отдельный проект.

VD>Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?

Надо просто запустить migrate.cmd из NRials.Demo, она создаст базу и нужные таблицы.

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

Z>Верно, ему для сборки нужна корректная БД. Для корректной БД нужна собранная NRails.Demo.Migrations и NRails.Console. Надо научиться компилировать миграции в памяти, без msbuild, тогда не нужен будет отдельный проект.

Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.

VD>>Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?

Z>Надо просто запустить migrate.cmd из NRials.Demo, она создаст базу и нужные таблицы.

Хм. Действительно помогло (только работало не быстро).

А нельзя ли их было в проект как пребилд-шаг воткнуть?

И что за странные ворнинги при сборке NRails.Demo?

E:\Program Files (x86)\Nemerle\Nemerle.MSBuild.targets(0,0):Warning: assembly 'E:\Program Files (x86)\Nemerle\Nemerle.dll' already loaded
E:\Program Files (x86)\Nemerle\Nemerle.MSBuild.targets(0,0):Warning: assembly 'E:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll' already loaded
E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Db.n(14,4):Warning: hint:
E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Doctor.n(8,6):Warning: hint:
E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Patient.n(8,4):Warning: hint:
E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Person.n(7,6):Warning: hint:

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

Z>Надо просто запустить migrate.cmd из NRials.Demo, она создаст базу и нужные таблицы.

Ну, что же. Приятно, что все запускается и работает почти "из коробки".

Но плохо, что не полностью из коробки.

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

VD>Главное здесь, то что шаблон (то что выглядит как функция) переопределяет (override, выделено жирным) шаблон объявленный в базовой группе шаблонов.
VD>Пользователь может заменить этот шаблон, но не может налепить черти чего.

Все таки наследование. Т.е. ST это просто чуть более удобный способ форматировать строки.

VD>Глупость не говори. Попробуй на досуге посимвольно конкатенировать строки. Увидишь, что даже на небольших строках начнутся тормоза, так как это экспонента.

Все эти тормоза на порядки быстрее выполнения команды которая в результате получилась. Выиграть <1% в некритичной по скорости операции?

Z>>У меня вполне читаемый sql получается. Конечно не идеально отформатированный, но для чтения человеком вполне достаточно.

VD>Читаемый без отступов? У нас видимо диаметрально противоположенные понятия о читаемости.

VD>А зачем не идеальный, когда можно получить идеально отформатированный код?
VD>В общем, "упорству храбрых поем мы песню...". Через зад но по-своему.

CREATE TABLE [SchemaMigrations] ([Version] NVARCHAR(255) NOT NULL,
         PRIMARY KEY ([Version]))

CREATE TABLE [Person] ([PersonID] INT IDENTITY (1,1) NOT NULL,
        [FirstName] NVARCHAR(50) NOT NULL,
        [LastName] NVARCHAR(50) NOT NULL,
        [MiddleName] NVARCHAR(50),
        [Gender] NCHAR(1) NOT NULL,
         PRIMARY KEY ([PersonID]))
CREATE TABLE [Doctor] ([PersonID] INT NOT NULL,
        [Taxonomy] NVARCHAR(50) NOT NULL,
        )
CREATE TABLE [Patient] ([PersonID] INT NOT NULL,
        [Diagnosis] NVARCHAR(256) NOT NULL,
        )

Я тебя правильно понимаю, что читабельность отсутствует и требуется переписать драйвер с нуля ради этого?

Z>>Кидаться переписывать драйвер БД изза них я не буду.

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

Я тоже переписываю код по тем же причинам. Но ресурсы не резиновые, я предпочту экспериментировать и полировать view engine, чем переписывать драйвер схемы БД ради идеальных отступов.

VD>Ведь у тебя еще не готовы драйверы для всех поддерживаемых БЛТулкитом СУБД?

Нет, но они есть в янусе.

VD>Найти в коде проекта код связанный с драйверами было очень не просто.

NRails.Database.Schema
NRails.Database.Mssql

Это было найти сложно?

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

Тут согласен. Я поправлю эти файлы, как только миграции будут более менее готовы, пока это способ не держать в студии десятки открытых файлов. Очень не хватает навигации решарпера

VD>Кстати, зачем было выбирать Меркури в качестве сорс-контрола? У меня на машине даже нечем скачать код.
VD>Пришлось тратить время на поиск и установку клиента.
VD>SVN вроде бы вполне приемлем для открытых проектов и его криент есть почти у всех. Тем самым ты сужаешь аудиторию.

hg давно один из стандартных VCS при открытой разработке. Поработав с ним на svn только за деньги работать хочется.

VD>Я бы сказал — это большой минус. Основные жалобы на янус всегда были связаны именно с реструктуризатором. К тому же он вроде бы не понимает всех СУБД которые знакомы БЛТулкиту.

А реструктуризатор мне как раз и не нужен, нужен код который был написан для него.

Z>>Написать с нуля и протестировать темплейты для всех БД я один не в состоянии.

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

Это основной аргумент в минус. Все остальное — попытки понять плюсы, единственный понятый это возможность идеально отформатировать SQL. Что достигается и другими средствами, гораздо проще чем переписывать все.

VD>>>Идея очень простая. Ты создаешь некий абстрактный DDL описывающий трансформации сущностей СУБД. Далее ты создаешь базовую группу шаблонов (аналогично классу) где для каждого элемента твоего абстрактного DDL-я имеется шаблон генерирующий текст (прикладной SQL). Этот базовый шаблон генерирует код на некотором диалекте SQL, напирмер, на TSQL. Далее ты (или кто-то другой) создаешь наследников этой группы шаблонов для каждой поддерживаемой СУБД и переопределяешь в нем реализацию тех элементов которые отличаются.

VD>Не так давно, ты утверждал, что проверки очень нужды

. Ну, да пока не надо — это тоже никудышный аргумент. Если проект дойдет до серьезного использования, то сложного SQL-я будет выше крыши.

Я не утверждал, что они нужны на каждом диалекте сиквела.

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

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

Z>>Верно, ему для сборки нужна корректная БД. Для корректной БД нужна собранная NRails.Demo.Migrations и NRails.Console. Надо научиться компилировать миграции в памяти, без msbuild, тогда не нужен будет отдельный проект.

VD>Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.

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

VD>>>Ну, и второй вопрос. Твои миграции саму БД будут создавать? Или БД всегда надо вручную создавать?

Z>>Надо просто запустить migrate.cmd из NRials.Demo, она создаст базу и нужные таблицы.

VD>Хм. Действительно помогло (только работало не быстро).

Ну базу надо создать. Еще тормоза в том, что я после каждого изменения перечитываю схему таблицы.

VD>А нельзя ли их было в проект как пребилд-шаг воткнуть?

Нельзя, это совсем не прибилд шаг.

VD>И что за странные ворнинги при сборке NRails.Demo?
VD>

VD>E:\Program Files (x86)\Nemerle\Nemerle.MSBuild.targets(0,0):Warning: assembly 'E:\Program Files (x86)\Nemerle\Nemerle.dll' already loaded
VD>E:\Program Files (x86)\Nemerle\Nemerle.MSBuild.targets(0,0):Warning: assembly 'E:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll' already loaded
VD>E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Db.n(14,4):Warning: hint:
VD>E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Doctor.n(8,6):Warning: hint:
VD>E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Patient.n(8,4):Warning: hint:
VD>E:\MyProjects\Tests\NRails\Demo\NRails.Demo\Models\Person.n(7,6):Warning: hint:

Насчет первых двух сам не знаю, надеюсь, что они исчезнут, когда переведу на шаблон MVC из сборки nemerle. Если нет надо будет копать.

А последние — эксперимент, попытка сделать тултипы для атрибутных макров

Наведи мышку на [Model] в Doctor.n.

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

VD>>Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.

Z>Хочется такого: выкачиваешь один проект, запускаешь миграцию, открываешь солюшен.

Отдельный то проект зачем?

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

Зачем? Эдак на реальной БД придется ждать по часу.

VD>>А нельзя ли их было в проект как пребилд-шаг воткнуть?

Z>Нельзя, это совсем не прибилд шаг.

Почему?

Z>Насчет первых двух сам не знаю, надеюсь, что они исчезнут, когда переведу на шаблон MVC из сборки nemerle. Если нет надо будет копать.

Судя по описания два раза подключаются стандартные библиотеки. Возможно в проекте выключен NoStdLib и при этом ссылки на стандартные сборки прописаны вручную. Или прописаны дважды.

Z>А последние — эксперимент, попытка сделать тултипы для атрибутных макров

Наведи мышку на [Model] в Doctor.n.

Нда...

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

VD>>>Да фиг бы с ним с проектом. Пускай будет. Просто логично было бы всю начальную инициализацию делать из этого проекта.

Z>>Хочется такого: выкачиваешь один проект, запускаешь миграцию, открываешь солюшен.

VD>Отдельный то проект зачем?

Не отдельный, а именно один проект над которым ты работаешь, в данном случае NRails.Demo.

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

VD>Зачем? Эдак на реальной БД придется ждать по часу.

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

VD>>>А нельзя ли их было в проект как пребилд-шаг воткнуть?

Z>>Нельзя, это совсем не прибилд шаг.

VD>Почему?

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

Z>>Насчет первых двух сам не знаю, надеюсь, что они исчезнут, когда переведу на шаблон MVC из сборки nemerle. Если нет надо будет копать.

VD>Судя по описания два раза подключаются стандартные библиотеки. Возможно в проекте выключен NoStdLib и при этом ссылки на стандартные сборки прописаны вручную. Или прописаны дважды.

Вобщем это локальные проблемы данного проекта, я его все равно поменяю скоро.

Z>>А последние — эксперимент, попытка сделать тултипы для атрибутных макров

Наведи мышку на [Model] в Doctor.n.

VD>Нда...

я уже видел эти ворнинги, наверное уберу хинты. Чем их заменить?

От:	VladD2	www.nemerle.org
Дата:	16.04.10 15:26
Оценка:	-1

От:	VladD2	www.nemerle.org
Дата:	16.04.10 16:51
Оценка:	+1

	От:	Ziaw
	Дата:	19.04.10 18:52
	Оценка:	-1

	От:	Воронков Василий
	Дата:	19.04.10 19:01
	Оценка:

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

	От:	dotneter
	Дата:	17.04.10 05:59
	Оценка:

	От:	dotneter
	Дата:	17.04.10 09:14
	Оценка: