Здравствуйте, 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>Кстати, а макросами можно реализовать глобальную замену использования одного класса на другой?

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

Здравствуйте, 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;

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

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

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

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

Здравствуйте, 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;

Здравствуйте, 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>Что-то я не понимаю о чем идет речь. Ты вроде бы говорил о правках чего-то в БД...

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

Здравствуйте, 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-ем вместо метаинформации? А как же тогда будет с поддержкой других серверов? Да и контроль будет на уровне плинтуса.

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

Здравствуйте, 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 сделал прямое включение кода на используемом языке в грамматику. Это суперудобно. Это то, что я хочу сделать. Если бы он стремился к той правильности о которой ты говоришь, он бы никогда такого не допустил.

Здравствуйте, 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 мне будет недостаточно . Но драйвер дело внутреннее, его реализация не должна трогать пользователя.

Здравствуйте, 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>Это все есть.

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