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

View engine. Дефолтный aspx достаточно неуклюж. Попробую перечислить его недостатки:

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

У меня зреет несколько вариантов, которые я хотел бы обсудить. Для примера возьмем простейшую вьюху: http://code.google.com/p/nemerleonrails/source/browse/Demo/NRails.Demo/Views/Home/Index.aspx

Spark

Движок который я сейчас применяю в MVC, о нем я уже рассказывал здесь, особо повторяться не буду, кто желает узнать поближе — http://sparkviewengine.com/

  <content name="Title">Home Page</content>

  <h1>!{model.Message}</h1>
  <p>Taxonomies list
    <ul>
      <li each='tax in model.Taxonomies'>!{tax}</li>
    </ul>

Плюсы:

• Очень читабельно и декларативно
  
• Движок уже поддерживает питон и руби, так что есть хороший шанс отделаться малой кровью при создании Nemerle аналога. Например Spark.Ruby это всего 13 cs файлов, < 40кб кода.
  
• Является надмножеством aspx, что очень облегчает переход на него.
  
• Легко расширяем.

Минусы:

• Непонятные перспективы, автор вроде бы ушел в майкрософт и там что-то делает в ASP.NET команде. Особого развития нет, хотя движок выглядит вполне законченным и легко расширяемым.
  
• Никакого контроля корректности html и автоескейпинга, хотя достаточно простой ручной ескейпинг.
  
• Интеграция в IDE. Есть только для 2008 студии, нет данных, что кто-то портирует под 2010, врядли она будет работать с языками отличными от C#. Для меня это большой и жирный минус, изза которого я вообще поднимаю эту тему, а не продумываю детали реализации спарка.

StringTemplate

Тут я описывать не буду особо, т.к. сам пока имею только печальный опыт попыток понять логику StringTemplate.

[StringTemplateGroup]
class Index_Home : View
{
  public title() : string {"Home Page"}

  [view] public view(model : Model) : string
  {
<#
  <h1>!{model.Message}</h1>
  <p>Taxonomies list
    <ul>
      ..$(model.Taxonomies; "\n";taxonomy)
    </ul>
#>
  }

  public taxonomy(name : string) : string {$"<li>$name</li>"}
}

Плюсы:

• есть готовый

Минусы:

• кошмарная читабельность, имхо
  
• слабая поддержка IDE внутри шаблонов
  
• достаточно большое количество синтаксического мусора

Код на Nemerle a la haml

Некий DSL на макрах, напоминающий haml. Python like indent + несколько несложных макров и код на nemerle начинает очень походить на haml. http://haml-lang.com/

[View] class Home_Index
  public title() : void
    t "Home Page" // t макрос вывода обычного текста, автоэскейпинг

  public view(model : Model) : void
    h1 model.Message
    p 
      t "Taxonomies list"
      ul
        foreach (tax in model.Taxonomies)
          li tax

Плюсы:

• Это действительно валидный код на nemerle, легко использовать все возможности языка, полная поддержка IDE.
  
• Достаточно прост в реализации.
  
• Очень легко расширяем
  
• Гарантирует валидный xml, и достаточно просто реализуется автоэскейпинг
  
• Если кому-то захочется красиво отформатированный html, здесь это будет сделать очень просто.

Недостатки:

• Непривычный вид будет отталкивать новичков.
  
• Динамическая компиляция внесет некие неявные особенности, которые придется учитывать. В спарке этой проблемы нет, он не выглядит как статически компилируемый код в проекте. К тому же для нормальной поддержки IDE его придется так же компилировать в проект. Впрочем для продакшена это неплохой бонус по времени раскочегаривания и объему памяти приложения (спарк тоже умеет компилировать все вьюхи в отдельную сборку).

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

Z>

Интеграция в IDE. Есть только для 2008 студии, нет данных, что кто-то портирует под 2010, врядли она будет работать с языками отличными от C#. Для меня это большой и жирный минус, изза которого я вообще поднимаю эту тему, а не продумываю детали реализации спарка.

где можно скачать интеграцию? Гляну на досуге, можно ли будет прикрутить поддержку nemerle

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

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

Z>>

Интеграция в IDE. Есть только для 2008 студии, нет данных, что кто-то портирует под 2010, врядли она будет работать с языками отличными от C#. Для меня это большой и жирный минус, изза которого я вообще поднимаю эту тему, а не продумываю детали реализации спарка.

S>где можно скачать интеграцию? Гляну на досуге, можно ли будет прикрутить поддержку nemerle

git://github.com/loudej/spark.git папка ./src/Tools

Хотя меня больше интересует 2010 студия.

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

S>где можно скачать интеграцию? Гляну на досуге, можно ли будет прикрутить поддержку nemerle

Вот тут еще идет переделка на vs2010 хотя, похоже, там все не так быстро
http://github.com/AndyHitchman/spark/commits/master

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

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

Z>>

Интеграция в IDE. Есть только для 2008 студии, нет данных, что кто-то портирует под 2010, врядли она будет работать с языками отличными от C#. Для меня это большой и жирный минус, изза которого я вообще поднимаю эту тему, а не продумываю детали реализации спарка.

S>где можно скачать интеграцию? Гляну на досуге, можно ли будет прикрутить поддержку nemerle

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

Это была бы суперфича, независимо от nrails, т.к. nemerle позиционируется как средство создания собственных DSL и написания парсеров. А так приходится выбирать, между удобством DSL и удобством разработки на нем.

Сейчас пока не хочется разбираться с интеграцией, если это нереально я лучше не буду начинать со спарка, т.к. плагин для 2008 студии может устареть до разработки, а для 2010 пока нет интеграции немерла.

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

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

Z>Это была бы суперфича, независимо от nrails, т.к. nemerle позиционируется как средство создания собственных DSL и написания парсеров. А так приходится выбирать, между удобством DSL и удобством разработки на нем.

Z>Сейчас пока не хочется разбираться с интеграцией, если это нереально я лучше не буду начинать со спарка, т.к. плагин для 2008 студии может устареть до разработки, а для 2010 пока нет интеграции немерла.

Хорошая мысль. Я пару дней буду в оффлайне, будет над чем подумать.

Компилятор умеет компилировать файлы:

using System.Console;

WriteLine("Test");

При этом создается класс с именем совпадающим с файлом и весь код кладется в метод Main.

У меня 2 вопроса:
1. Можно ли научить интеграцию работать в таком файле?


2. Можно ли научить компилятор генерить этот класс в неймспейс, например как относительный путь от ProjectFolder
(этим я могу заняться сам, мне нужно добро только)
Это ничего не должно поломать по идее, т.к. по большей части такой синтаксис используется для скриптовых вещей, а там все равно в каком неймспейсе класс.

Для чего это требуется:

Вьюха вполне может выглядеть так:

#pragma indent
using NRails.Haml

content title
  t "Home Page"

def taxView(tax)
  li tax

h1 model.Message
p 
  t "Taxonomies list"
  ul
    foreach (tax in model.Taxonomies)
      taxView(tax)

А может так:

#pragma indent
using NRails.Haml

class Home_Index
  public title() : void
    t "Home Page"

  public view(model : Model) : void
    def taxView(tax)
      li tax

    h1 model.Message
    p 
      t "Taxonomies list"
      ul
        foreach (tax in model.Taxonomies)
          taxView(tax)

Первый вариант уже вылитый haml, такой энжин не стыдно показать, в нем будет приятно работать.
Второй — больше походит на костыли и точно не получит популярности.

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

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

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

Z>У меня 2 вопроса:
Z>1. Можно ли научить интеграцию работать в таком файле?

Сейчас это не поддерживается. Но в принципе это возможно (хотя может оказаться не просто).

Но макросам на такое закладываться, на мой взгляд, не стоит.

Z>2. Можно ли научить компилятор генерить этот класс в неймспейс, например как относительный путь от ProjectFolder

Конечно возможно все, но это уже какие-то переделки компилятора под нужны конкретного макроса.
Мне кажется это не очень хорошая идея.

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

Там уже меняли имя класса и т.п. Зачем не помню.

Z>Для чего это требуется:

Z>Вьюха вполне может выглядеть так:
Z>

Z>#pragma indent
Z>using NRails.Haml

Z>content title
Z>  t "Home Page"

Z>def taxView(tax)
Z>  li tax

Z>h1 model.Message
Z>p 
Z>  t "Taxonomies list"
Z>  ul
Z>    foreach (tax in model.Taxonomies)
Z>      taxView(tax)
Z>

Может, наверно. Вопрос в том насколько это разумно.

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

Плюс этот подход подразумевает, что весь код вьюхи будет обязан располагаться в одном методе.
А это плохо сразу по нескольким причинам:
1. Это мешает модульности. Многие части вьюх будут весьма универсальными решениями. Их нужно оформалять как отдельные методы, а данная схема будет этому препятствовать.
2. Вьюхи могут получаться весьма большими. Текущая версия интеграции может начать тормозить на них. Точнее обязательно начнет (особенно если в коде будет много перегруженных методов).

Z>А может так:
Z>

Z>#pragma indent
Z>using NRails.Haml

Z>class Home_Index
Z>  public title() : void
Z>    t "Home Page"
Z>...

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

На костыли похожи оба варианта. Хотя в принципе оба будут приемлемыми. С комплитом, правда, могут быть проблемы.

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

Ну, если понимать под принципом использование некоторого типизированного AST HTML-я, то — да, согласен — это верный подход.
Если под принципом понимается эмуляция хтмл-я на базе макросов похожих по названию на теги, то — это далеко не самое интуитивное и элегантное решение.

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

Я предлагаю совместить идею построения типизированного AST для HTML с идеей синтаксического макроса с синтаксисом похожим на Spark (и частично на $-строки (в части квази-цитирования, чтобы не заставлять программистов изучать новую нотацию)).

Выглядеть это должно так:
1. Мы описываем AST в виде вариантов или классов и позволяем расширять эту иерархию прикладному программисту (который будет использовать движок).
2. Мы создаем макрос который будет принимать на входе специаилизированный синтаксис аля Spark с квази-цитатами и преобразующий его в AST по некоторым принципам. Выглядеть это будет примерно так:

[MvcView]
class MyView
{
  public MainRender(model : SomeModelData) : Nemerle.NRials.HtmlAst
  {
    html <#
     <h1>$(model.Message)</h1>
     <p>Taxonomies list
       <ul>
         <li each='tax in model.Taxonomies'>$tax</li>
       </ul>
     </p>
    #>
  }
}

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

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

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

Макрос html будет парсить переданную ему строку и выявлять структуру тегов, их имена и спалйсы. Далее он будет строить AST элементы которого будет соответствовать именам тегов разобранных из строки. Встречая сплайс он будет вставлять содержимое получаемое путем вычисления выражений из сплайсов. Таким образом спласы могут содержать ссылки на куски АСТ или функции его формирующие. Можно даже пойти дальше и сделать отложенный ренедирг сплайсов. Тогда будет не важно их расположение в коде. Конечный HTML будет получаться путем вычисления всех вложенных свлайсов и материализации всех его элементов. Далее останется только лишь вызвать функцию преобразования этого AST в строку.

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

VD>Конечно возможно все, но это уже какие-то переделки компилятора под нужны конкретного макроса.
VD>Мне кажется это не очень хорошая идея.

Не макроса, а движка. Ты говорил, что все в наших руках

VD>Там уже меняли имя класса и т.п. Зачем не помню.

Можно неаврное найти в логах

VD>Может, наверно. Вопрос в том насколько это разумно.

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

Принцип взят со вполне удачного хамла.

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

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

Как раз нет. Макрос контент вынесет тело во внешний метод.

VD>2. Вьюхи могут получаться весьма большими. Текущая версия интеграции может начать тормозить на них. Точнее обязательно начнет (особенно если в коде будет много перегруженных методов).

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

Z>>А может так:
Z>>

Z>>#pragma indent
Z>>using NRails.Haml

Z>>class Home_Index
Z>>  public title() : void
Z>>    t "Home Page"
Z>>...

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

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

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

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

На самом деле оба. Я снова не стал изобретать велоспед, а взял за основу синтаксис хамла.

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

Про метод я писал, получается статик класс, методы нужные для конкретно этой вьюхи делаются локальными функциями, методы которые должны быть доступны снаружи (генерят разные части вьюхи, типа title) объявляются макросом и выносятся в класс.

VD>Я предлагаю совместить идею построения типизированного AST для HTML с идеей синтаксического макроса с синтаксисом похожим на Spark (и частично на $-строки (в части квази-цитирования, чтобы не заставлять программистов изучать новую нотацию)).

VD>Выглядеть это должно так:
VD>1. Мы описываем AST в виде вариантов или классов и позволяем расширять эту иерархию прикладному программисту (который будет использовать движок).
VD>2. Мы создаем макрос который будет принимать на входе специаилизированный синтаксис аля Spark с квази-цитатами и преобразующий его в AST по некоторым принципам. Выглядеть это будет примерно так:
VD>

VD>[MvcView]
VD>class MyView
VD>{
VD>  public MainRender(model : SomeModelData) : Nemerle.NRials.HtmlAst
VD>  {
VD>    html <#
VD>     <h1>$(model.Message)</h1>
VD>     <p>Taxonomies list
VD>       <ul>
VD>         <li each='tax in model.Taxonomies'>$tax</li>
VD>       </ul>
VD>     </p>
VD>    #>
VD>  }
VD>}
VD>

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

ты только что объединил недостатки обоих движков, у нас больше нет комплита и появилась куча синтаксического мусора в виде класса, методов, макросов, типов. Это все выводится. Класс совпадает с именем файла, главный рендер должен быть один и он обязан быть всегда. Указывать надо только доп кусочки для лейаута (conent title). То, что это MvcView известно по папке в которой лежит файл, то, что вьюха принимает SomeModelData задается макросом в контроллере, то, что она генерит Html и так понятно. При этом на реализацию автокомплита и хайлайта а нам требуется больше усилий чем для спарка (там уже есть парсеры и хайлайтеры для студии). Почему не спарк тогда? Проще его научить генерить этот АСТ, хотя я пока не могу придумать полезных задач для его разбора или изменения программно. Зато ресурсы будут кушаться неслабо, тот же спарк тупо пишет все в стрим это очень быстро и жрет минимум ресурсов. А вот здоровый html придется сначала выстроить в памяти, а потом уже скидывать в стрим. Хотя сервер мог уже отдать половину страницы к тому времени, пока мы генерим остатки.

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

Я все еще не убежден, в необходимости генерить АСТ, но как опцию готов вставить это в хамл. Но хамл с мусором тоже нафик не уперся

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

Ну этот вопрос решается точно так же и в спарке и в хамле.

VD>Макрос html будет парсить переданную ему строку и выявлять структуру тегов, их имена и спалйсы. Далее он будет строить AST элементы которого будет соответствовать именам тегов разобранных из строки. Встречая сплайс он будет вставлять содержимое получаемое путем вычисления выражений из сплайсов. Таким образом спласы могут содержать ссылки на куски АСТ или функции его формирующие. Можно даже пойти дальше и сделать отложенный ренедирг сплайсов. Тогда будет не важно их расположение в коде. Конечный HTML будет получаться путем вычисления всех вложенных свлайсов и материализации всех его элементов. Далее останется только лишь вызвать функцию преобразования этого AST в строку.

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

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

Z>View engine. Дефолтный aspx достаточно неуклюж. Попробую перечислить его недостатки:

Надо учитывать, что представления должны быть полностью локализируемы. То есть, строки все равно должны по возможности содержаться не в самих представлениях, а в БД. Что дает дополнительные очки для движков, которые рендерят абстрактные деревья, а не копипастят строки со вставками.

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

VD>>Конечно возможно все, но это уже какие-то переделки компилятора под нужны конкретного макроса.
VD>>Мне кажется это не очень хорошая идея.

Z>Не макроса, а движка. Ты говорил, что все в наших руках

Тогда что ты понимашь под движком? Я что-то потерял мысль.

Z>Принцип взят со вполне удачного хамла.

Это я понял. Да и с Руби знаком немного.

VD>>1. Это мешает модульности. Многие части вьюх будут весьма универсальными решениями. Их нужно оформалять как отдельные методы, а данная схема будет этому препятствовать.

Z>Как раз нет. Макрос контент вынесет тело во внешний метод.

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

VD>>2. Вьюхи могут получаться весьма большими. Текущая версия интеграции может начать тормозить на них. Точнее обязательно начнет (особенно если в коде будет много перегруженных методов).

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

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

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

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

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

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

Про "объявляются макросом и выносятся в класс" я опять же не понял.

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

Комплит для параметров будет. Для тегов он не особо нужен.

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

Z>Это все выводится. Класс совпадает с именем файла, главный рендер должен быть один и он обязан быть всегда.

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

Z>Указывать надо только доп кусочки для лейаута (conent title). То, что это MvcView известно по папке в которой лежит файл,

О! Еще и магические папки?

Z>то, что вьюха принимает SomeModelData задается макросом в контроллере,

Опять же не понял.

Z>то, что она генерит Html и так понятно.

А вот это не очевидно. Генерироваться может ХМЛ. Да и что плохого если это будет явно видно?

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

Про комплит я уже говорил.

Z> Почему не спарк тогда?

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

Z>Проще его научить генерить этот АСТ, хотя я пока не могу придумать полезных задач для его разбора или изменения программно.

Зато я могу. И вообще работа с текстом — это грандиозная ошибка дизайна.

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

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

Ты не там блох ловишь. Скорость будет выше крыши. А вот надежность и удобство ты с текстом не получишь.

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

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

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

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

Z>Я все еще не убежден, в необходимости генерить АСТ, но как опцию готов вставить это в хамл. Но хамл с мусором тоже нафик не уперся

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

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

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

Z>Ну этот вопрос решается точно так же и в спарке и в хамле.

Покажи как.

VD>>Макрос html будет парсить переданную ему строку и выявлять структуру тегов, их имена и спалйсы. Далее он будет строить AST элементы которого будет соответствовать именам тегов разобранных из строки. Встречая сплайс он будет вставлять содержимое получаемое путем вычисления выражений из сплайсов. Таким образом спласы могут содержать ссылки на куски АСТ или функции его формирующие. Можно даже пойти дальше и сделать отложенный ренедирг сплайсов. Тогда будет не важно их расположение в коде. Конечный HTML будет получаться путем вычисления всех вложенных свлайсов и материализации всех его элементов. Далее останется только лишь вызвать функцию преобразования этого AST в строку.

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

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

Ну, и в конце концов ты можешь реализовать все это дело с помощью паттерна Builder. Тогда один Concrete Builder будет тебе создавать АСТ, а другой сразу генерировать текст, предварительно проверив данные на вшивость.

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

C>Надо учитывать, что представления должны быть полностью локализируемы. То есть, строки все равно должны по возможности содержаться не в самих представлениях, а в БД.

Локализация совершенно отдельная тема. И БД тут лишь одно из решений.

C>Что дает дополнительные очки для движков, которые рендерят абстрактные деревья, а не копипастят строки со вставками.

Какие?

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

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

VD>>>Конечно возможно все, но это уже какие-то переделки компилятора под нужны конкретного макроса.
VD>>>Мне кажется это не очень хорошая идея.

Z>>Не макроса, а движка. Ты говорил, что все в наших руках

VD>Тогда что ты понимашь под движком? Я что-то потерял мысль.

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

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

VD>>>2. Вьюхи могут получаться весьма большими. Текущая версия интеграции может начать тормозить на них. Точнее обязательно начнет (особенно если в коде будет много перегруженных методов).

Каким образом мелкие вьюхи достигаются у тебя? Подумай, что мешает делать это в моих движках?

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

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

Рекрсию можно сделать через локальные функции и внешние контролы.

Грубо говоря есть 3 вида вьюх:

1. Layout, это скелет страницы, рендерит внутри себя куски конкретной вьюхи, у сайта их несколько, конкретный выбирается вьюхой, аналог мастера, он не преполагает никакой рекурсии, она ему тупо не нужна. С размером борьба идет с помощью контролов, один на запрос.
   
2. View, генерит нужные конкретные куски в лейаут, один главный кусок есть всегда, остальные по желанию. Лейаут может распознать какие куски ему дали, а какие нет. Одна на запрос. Потому не рекурсивна.
   
3. Control, может быть вызван их любого другого места, содержит только один кусок, может вызывать другие контролы и себя в том числе.

VD>Я не понимаю, что понимается под "кучей мелких вьюх". На мой взгляд, вьюхи должны формироваться из кусков. Сплайсы решают проблему разбиение монолитного дерева на части. Возможность размещать редеринг в разных методах решает проблему ренедеренга частей и формирования библиотек шаблонов (причем умных).

мелкие вьюхи по этой классификации это вынос кусков из Layout и View в Controls. Сплайсы решают проблему не хуже и не лучше других.

VD>Я же тебе только что выше писал. Это будет тормозить. Локльные фукнции разбираются только в рамках метода в котором они объявлены. Если кода в таком методе будет много или будет много перегрузок, то тормоза неизбежны.

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

VD>Про "объявляются макросом и выносятся в класс" я опять же не понял.

Макрос, который код внутри себя выносит в метод класса.

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

VD>Комплит для параметров будет. Для тегов он не особо нужен.

Влад, ну это же херня полная. Пофик что это внутри АСТ программисту это преподносится как голая строка. Для парамтров у меня кстати тоже мало что работает, model.taxanomy точно не работает. А хайлайтинг в тегах тоже блажь?

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

Локальные функции ничем не хуже.

Z>>Это все выводится. Класс совпадает с именем файла, главный рендер должен быть один и он обязан быть всегда.

VD>Я не знаю что такое "главный рендер", но идея что-то там выводить из имен файлов мне не нравится. В Яве по этому пути пошли и вышло не очень здорово. А у нас не Ява, а дотнет в котором этот подход не принят.
VD>О! Еще и магические папки?
VD>Опять же не понял.
VD>А вот это не очевидно. Генерироваться может ХМЛ. Да и что плохого если это будет явно видно?

В рельсах будет все работать на соглашениях, это не обсуждается. Как минимум уже есть куча соглашений о том, что модель называется так же как и таблица, поля в ней просто список колонок, тип колонок в миграциях это тоже соглашения. То, что контроллер это класс который заканчивается на Controller — тоже соглашение, хотя и из Mvc, про вьюхи соглашение оттуда же, имя класса там вообще гуид и не играет никакой роли, у меня скорее всего будет также когда вьюхи начнут компилироваться динамически.

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

VD>Про комплит я уже говорил.

То, что он и не нужен. Не согласен.

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

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

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

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

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

VD>Ты не там блох ловишь. Скорость будет выше крыши. А вот надежность и удобство ты с текстом не получишь.

А память? Это все надо строить в памяти.

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

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

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

При чем тут куски? Это поток, какими кусками его будет отдавать сервер это не наше дело в данном слое.

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

Ты так и не показал, чем это рекурсивнее хамла или спарка. И чем синтаксис полноценнее тоже.

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

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

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

Z>>Ну этот вопрос решается точно так же и в спарке и в хамле.

VD>Покажи как.

А так, что все строки в поток выводит движок. Ескейпить или нет он тоже может подумать. И синтаксис проверить тоже.

VD>Блин. Создай тест. Залуди в нем дерево и его эффективное преобразование в текст (с помощью СтрингБилдера) и погляди сколько времени занимает формирвоание дерева. Поймешь, что то говоришь не о чем. Это считанные миллисекунды. А результат будет отдаваться точно так же потоком.

частные случаи мне неинтересны. Создай тест, возьми 10 мегабайтный текст и сделай 2 реализации команды cat (type) одну через read -> write, вторую через readall->ast->render. Сразу заметишь разницу.

VD>Ну, и в конце концов ты можешь реализовать все это дело с помощью паттерна Builder. Тогда один Concrete Builder будет тебе создавать АСТ, а другой сразу генерировать текст, предварительно проверив данные на вшивость.

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

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

VD>>>>Конечно возможно все, но это уже какие-то переделки компилятора под нужны конкретного макроса.
VD>>>>Мне кажется это не очень хорошая идея.

Z>>>Не макроса, а движка. Ты говорил, что все в наших руках

VD>>Тогда что ты понимашь под движком? Я что-то потерял мысль.

Z>Движок это систама превращающая некий код в html.

Это очень абстрактно. Фактически это подтягивание интеграции под твои личные задумки.

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

Я так понимаю, что твои li, t, p — это маросы. Иначе в немерле невозможно будет писать такой код (не указывая скобок).

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

Z>Каким образом мелкие вьюхи достигаются у тебя?

Декомпозицией основанной на рекурсивном дизайне. Просто не нужно весь код страницы впихивать в один метод (вьюхи или еще что-то). Рендеринг для вьюхи должен состоять из больших блоков где каждый подблок — это отдельный метод который так же мал. Скажем рендеринг списка не требует указания li и foreach. Вместо этого нужно просто сослаться на другой метод который сформирует код списка. Так же фигня с таблицами и многим другим. Скажем, если мы хотим получить меню, то код рендеренга меню должен лежать в библиотеки, а мы должны всего лишь вызвать его передавая ему необходимые данные.

Z>Подумай, что мешает делать это в моих движках?

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

Z>Рекрсию можно сделать через локальные функции и внешние контролы.

Локальные функции не приемлемы по уже озвученным причинам. Это рано или поздно приведет к тормозам. Надо учитывать реалии мира, а не переть против них.

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

Z>Грубо говоря есть 3 вида вьюх:

Z>

Z>
1. Layout, это скелет страницы, рендерит внутри себя куски конкретной вьюхи, у сайта их несколько, конкретный выбирается вьюхой, аналог мастера, он не преполагает никакой рекурсии, она ему тупо не нужна. С размером борьба идет с помощью контролов, один на запрос.
   Z>
2. View, генерит нужные конкретные куски в лейаут, один главный кусок есть всегда, остальные по желанию. Лейаут может распознать какие куски ему дали, а какие нет. Одна на запрос. Потому не рекурсивна.
   Z>
3. Control, может быть вызван их любого другого места, содержит только один кусок, может вызывать другие контролы и себя в том числе.
   Z>

Понятно. Это дизайн ASP. Он исходно ущербен. Теперь представь себе почти тот же дизайн, но выкини из него первых два пунка и создай еще один. Назовем его условно "правило рендеренга" (RendererRule). Оно почти такое же как описанные тобой Layout и View, но допускает неограниченную вложенность (возов других RendererRule или себя же). Тогда Layout-ом будет просто RendererRule задающее общий дизайн страницы. View тоже будут RendererRule, но уже вложенные в Layout. При том они так же могут содержать обращения к RendererRule которые в свою очередь так же могут обращаться к другим RendererRule.

В итоге мы получим возможность компоновать страницу из весьма мелкий и от того очевидных RendererRule. Кроме того это позволит сделать RendererRule сущностью высшего порядка (ссылку на RendererRule можно будет передать в качестве параметра другого RendererRule чтобы тот использовал его внутри себя).

Z>мелкие вьюхи по этой классификации это вынос кусков из Layout и View в Controls. Сплайсы решают проблему не хуже и не лучше других.

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

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

VD>>Я же тебе только что выше писал. Это будет тормозить. Локльные фукнции разбираются только в рамках метода в котором они объявлены. Если кода в таком методе будет много или будет много перегрузок, то тормоза неизбежны.

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

Причем тут Решапрер? Я писал код о котором говорю. И точно знаю его плюсы и минусы.

И вообще, зачем ты с кем-то советуешься если ни одна чужая мысль тебя заранее не интересует?

VD>>Про "объявляются макросом и выносятся в класс" я опять же не понял.

Z>Макрос, который код внутри себя выносит в метод класса.

Все равно не понятно. Опиши подробнее.

VD>>Комплит для параметров будет. Для тегов он не особо нужен.

Z>Пофик что это внутри АСТ программисту это преподносится как голая строка.

Да ну? Ты когда $-строки используешь сплайсы в них как голые строки рассматриваешь?
Та же фигня будет и здесь. Если макрос контролирует содержимое этой строки, то для программиста это уже будет не голая строка, а весьма четкий код. На ошибки в нем компилятор (и IDE) будет ругаться. Некорректные конструкции не пройдут компиляцию. Даже некорректная вложенность тегов будет контролироваться. Скажем тег <title> нельзя будет вложить никуда кроме как в <head>, а <head> в только в <html>. Точно так же будет с <td>, <tr> и <table>. Ошибочное имя тега будет сразу же подсвечено компилятором.

Z>Для парамтров у меня кстати тоже мало что работает, model.taxanomy точно не работает.

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

Z>А хайлайтинг в тегах тоже блажь?

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

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

Z>Локальные функции ничем не хуже.

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

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

Z>В рельсах будет все работать на соглашениях, это не обсуждается.

Что же мешает обсуждению столь не очевидного дизайна?

Z>Как минимум уже есть куча соглашений о том, что модель называется так же как и таблица

В БЛтулкит я могу задать любой имя атрибутом. Почему это не использовать?
А если в БД у меня таблицы названы в стиле ИМЯ_МОЕЙ_ТАБЛИЦЫ, а в коде я хочу иметь имена в виде ИмяМоейТаблицы?

Z>, поля в ней просто список колонок, тип колонок в миграциях это тоже соглашения.

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

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

Z> То, что контроллер это класс который заканчивается на Controller — тоже соглашение, хотя и из Mvc,

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

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

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

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

Z>Контрол может вызывать сам себя.

Мне вообще не очень нужны твои контролеры. Если они будут я конечно не обижусь. Но и без них было бы не плохо.

Z>Какую еще рекурсию ты хочешь?

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

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

Еще раз советую почитать о дизайне того же StringTemplate (не немерлового, а исходного, там много хороших статей).
Пойми же на конец, что повторять плохой дизайн не нужно. HTML и XML — это рекурсивные древесные структуры и только рекурсией можно сделать его рендеринг действительно удобным. Это еж элементарно! Неужели это так трудно осознать?

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

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

Z>Первый критерием является удобство работы.

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

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

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

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

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

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

Ты этого хочешь?

Z>А память? Это все надо строить в памяти.

Самый наргуженный сайт имеет сотри параллельных запросов (ну тысячи в крайних случаях). Это несколько десятков метров памяти, а то и метров. Нужна эта память будет на пару миллисекунд. Она даже не будет попадать в первое поколения (в 99% случаев сдыхая в нулевом).

К примеру, компиляция самого большого проекта немерла (компилятора) отнимает у системы около ста метров памяти. При этом все исходники компилятора, а это где-то 1.5 метра исходников поднимаются в память и превращаются сначала в список токенов (где каждый токен превращается в объект), потом по нему создается нетипизированное АСТ, а затем по нему типизированный. Плюс каждый тип превращается в один или более объектов (и это для каждой функции).

Страница в вебе никогда в жизни не приблизится по объему АСТ к коду компилятора. Так что можно смело забить на эти затраты.

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

Сделай тесты. Уверяю тебя — ты занимавшийся теми самыми предварительными оптимизациями.

Z>Ты так и не показал, чем это рекурсивнее хамла или спарка. И чем синтаксис полноценнее тоже.

Я не знаком со спарком. Уверен, что хамл как раз таки рекурсивен. Возможно спарк тоже рекурсивен. Но ты пытаешься создать их не рекурсивные версии. И это очень печально.

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

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

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

Где я говорил про StringTemplate? Я говорю о дизайне. Как раз StringTemplate тут не лучший выход. Но не потому что там есть жуткие методы (это как раз фигня), а потому, что он работает с текстом. А текст нельзя проверять.

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

Z>>>Ну этот вопрос решается точно так же и в спарке и в хамле.

VD>>Покажи как.

Z>А так, что все строки в поток выводит движок. Ескейпить или нет он тоже может подумать. И синтаксис проверить тоже.

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

Z>частные случаи мне неинтересны. Создай тест, возьми 10 мегабайтный текст и сделай 2 реализации команды cat (type) одну через read -> write, вторую через readall->ast->render. Сразу заметишь разницу.

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

VD>>Ну, и в конце концов ты можешь реализовать все это дело с помощью паттерна Builder. Тогда один Concrete Builder будет тебе создавать АСТ, а другой сразу генерировать текст, предварительно проверив данные на вшивость.

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

Ты почитай про паттерн на который я тебе дал ссылку. Он позволяет абстрагироваться от операции выполняемой макросом render. Вместо того чтобы строить АСТ ты сможешь просто писать данные в поток. Точно так же как если бы ты работал не с АСТ, а с текстом. Понятное дело, что многие преимущества будут при этом потеряны, но зато это даст возможность путем подмены билдера получить или минимизацию ресурсов при прямой записи в поток, или дополнительную проверку корректнсоти и обработки при построении АСТ.

Короче Билдер позволяет сделать сменные "насадки". Выглядит это примерно так:

interface AbstratctRenderer
{
  Title(text : string);
  TableStart(tbleTata : TbleTata);
  TableEnd();
  TdStart(...);
  TdEnd(...);
  TrStart(...);
  TrEnd(...);
}

Ну, а далее делаешь две реализации. Ода создает АСТ. Другая пишет в поток.

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

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

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

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

VD>Локальные функции не приемлемы по уже озвученным причинам. Это рано или поздно приведет к тормозам. Надо учитывать реалии мира, а не переть против них.

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

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

VD>Понятно. Это дизайн ASP. Он исходно ущербен. Теперь представь себе почти тот же дизайн, но выкини из него первых два пунка и создай еще один. Назовем его условно "правило рендеренга" (RendererRule). Оно почти такое же как описанные тобой Layout и View, но допускает неограниченную вложенность (возов других RendererRule или себя же). Тогда Layout-ом будет просто RendererRule задающее общий дизайн страницы. View тоже будут RendererRule, но уже вложенные в Layout. При том они так же могут содержать обращения к RendererRule которые в свою очередь так же могут обращаться к другим RendererRule.

Это паттерн любого taemplate engine для веба, твои рулы придут к нему, только подзже, разве что можно стереть разницу между view и control, но на уровне логики она останется. Именно в том, что вьюха рекурсивной быть не может.

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

Layout.spark

<html>
<head>
  <title><use content="title">My site</use></title>
</head>
<body>
  <use content="view"/>
</body>
</html>

Вьюха отвечает за текущий респонс, контроллер, подготовив данные, отдает их view (или контролу если рендерит кусок страницы)
Index.spark

<content name="title">Taxonomies</content>

<h1>!{model.Message}</h1>
  <p>Taxonomies list
  <ul>
     <!-- Контрол -->
     <Tax each='tax in model.Taxonomies' tax="tax"/> 
  </ul>
</p>

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

<viewdata tax="string">

<li>!{tax}</li>

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

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

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

Да технически они могут быть рекурсивны! Это логическое ограничение. Также насчет вызова других.

VD>>>Я же тебе только что выше писал. Это будет тормозить. Локльные фукнции разбираются только в рамках метода в котором они объявлены. Если кода в таком методе будет много или будет много перегрузок, то тормоза неизбежны.

Да немного кода во вьюхах, совсем немного.

VD>Причем тут Решапрер? Я писал код о котором говорю. И точно знаю его плюсы и минусы.

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

VD>И вообще, зачем ты с кем-то советуешься если ни одна чужая мысль тебя заранее не интересует?

Как тебе сказать У меня возникло 2 направления для получения хорошего результата с минимальными затратами. Оба неидеальны так как требуют некоторой допилки IDE или компилятора что возможно только при консультации с тобой. В ответ получил сырую рекомндацию писать все с нуля. В итоге получится StringTemplate без поддержки IDE, удобный для организации контента, но очень неудобный для его написания, отладки и поддержки. Извини, но с чего ты взял, что она должна меня заинтересовать?

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

VD>>>Про "объявляются макросом и выносятся в класс" я опять же не понял.

Например так:

content Title // обявляются макросом
  t "Taxonomies"

//...

V

module Home_Index
  public Title() : void
    t "Taxonomies"

  public Main() : void
    title = fun()
    //...

Z>>Пофик что это внутри АСТ программисту это преподносится как голая строка.

VD>Да ну? Ты когда $-строки используешь сплайсы в них как голые строки рассматриваешь?

Ты не поверишь, именно как сахар для String.Format, все кроме сплайсов голая строка.

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

Да не будет он для программиста кодом, для IDE это строка.

VD>Если что-то не работает, описывай баг-реквест. Будем исправлять.

Баг реквест, что индент синтаксис не работает есть или написать?

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

Твой макрос будет парсить на PExpr, а строку, какой там код?

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

Пятый раз повторяю, что выносить можно.

VD>Что же мешает обсуждению столь не очевидного дизайна?

Это очевидный дизайн. Он объявлялся с самого начала, все, для чего достаточно соглашений, будет оформлено на соглашениях.

VD>В БЛтулкит я могу задать любой имя атрибутом. Почему это не использовать?

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

VD>А если в БД у меня таблицы названы в стиле ИМЯ_МОЕЙ_ТАБЛИЦЫ, а в коде я хочу иметь имена в виде ИмяМоейТаблицы?

Это планируется решать на уровне настроек драйвера БД.

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

Это все зависит от ControllerFactory & ViewFactory, фактически по строковым параметрам они должны выдать нужные сущности. Методы регистрации этих сущностей в MVC разные, для View это расположение в нужной папке с нужным именем. Лучшего способа для рантайм регистрации придумать сложно.

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

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

VD>Самый наргуженный сайт имеет сотри параллельных запросов (ну тысячи в крайних случаях). Это несколько десятков метров памяти, а то и метров. Нужна эта память будет на пару миллисекунд. Она даже не будет попадать в первое поколения (в 99% случаев сдыхая в нулевом).

А ты предлагаешь запросу выхватить мегабайты, которые лягут в LOH.

VD>Страница в вебе никогда в жизни не приблизится по объему АСТ к коду компилятора. Так что можно смело забить на эти затраты.

Ничего не понял.

VD>Я не знаком со спарком. Уверен, что хамл как раз таки рекурсивен. Возможно спарк тоже рекурсивен. Но ты пытаешься создать их не рекурсивные версии. И это очень печально.

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

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

VD>>>Покажи как.

Точно так же как в твоем примере. Строка в них сама по себе в HTML не попадает.

VD>Короче Билдер позволяет сделать сменные "насадки". Выглядит это примерно так:
VD>Ну, а далее делаешь две реализации. Ода создает АСТ. Другая пишет в поток.

АСТ тогда зачем? Я все еще не увидел ни одного внятного объяснения о необходимости этого AST. Давай начнем со сценариев использования, перейдем к требованиям, а потом уже будем думать о реализации. А никак не наоборот.

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

S>Хорошая мысль. Я пару дней буду в оффлайне, будет над чем подумать.

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

Вобщем вопрос с выбором вьюенжина отпадает, буду мучать спарк помаленьку. Надо прикрутить к нему матчи и локальные функции.

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

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

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

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

VD>>Локальные функции не приемлемы по уже озвученным причинам. Это рано или поздно приведет к тормозам. Надо учитывать реалии мира, а не переть против них.

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

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

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

Z>Это паттерн любого taemplate engine для веба, твои рулы придут к нему, только подзже, разве что можно стереть разницу между view и control, но на уровне логики она останется. Именно в том, что вьюха рекурсивной быть не может.

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

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

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

Твои контролы, кстати, нужны именно по причине монолитности твоих вьюх и лэйяутов. Это эдакий хак в монолитном дизайне позволяющий хоть как-то ввести декомпозицию. Если каждый элемент может ссылаться на себе подобные, то контролы не очень то и нужны. Они мало чем будут отличаться от универсальных RendererRule специализированных некоторыми параметрами (эдаких замыканий).

Z>Layout.spark
Z>

Z><html>
Z><head>
Z>  <title><use content="title">My site</use></title>
Z></head>
Z><body>
Z>  <use content="view"/>
Z></body>
Z></html>
Z>

И что тут уникального? Зачем-то введены какие-то не внятные "<use content="title">" и "<use content="view"/>". По сути это так же функция с двумя параметрами title и view.

Кстати, я правильно понимаю, что содержимое для "<use content="title">" задается в "<content name="title">Taxonomies</content>"?

Если "да", то такое решение не будет работать в случае прямой записи в стрим, так как значение для content name="title" задается сильно позже записи заголовка.

На лицо та же самая организация объектной модели страницы с которой ты так борешся.

Z>Вьюха отвечает за текущий респонс, контроллер, подготовив данные, отдает их view (или контролу если рендерит кусок страницы)
Z>Index.spark
Z>

Z><content name="title">Taxonomies</content>

Z><h1>!{model.Message}</h1>
Z>  <p>Taxonomies list
Z>  <ul>
Z>     <!-- Контрол -->
Z>     <Tax each='tax in model.Taxonomies' tax="tax"/> 
Z>  </ul>
Z></p>
Z>

Замечательно. Ну, и чем это толичается от лэйаута? Это тоже функция, но в этот раз ней кроме нердерегна содержимого еще задается значение некой глобальной переменной (что является плохим дизайном).

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

Z><viewdata tax="string">

Z><li>!{tax}</li>
Z>

Приседания — это плохо, но то что я вижу это опять таки аналог функции.

Обрати внимание. Каждая "функция" в такой модели получается весьма маленькой. Какой смысл запихивать такие микроскопические куски кода в отдельные файлы?

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

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

Z>По идее мы и в спарке можем это сделать, в смысле дописать спарк, а не писать с нуля.

Не спорю. Наверно. Спарк тоже не идиоты делали. Его проблемы ты уже обрисовал.
Мы можем сделать тоже самое что в Спарке, только с качественным контролем времени компиляции и интеллесенсом для параметров.

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

Z>Да технически они могут быть рекурсивны! Это логическое ограничение. Также насчет вызова других.

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

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

Это функциональный дизайн. Он для обработки деревьев просто идеальный.

А Спарк не смотря на элегантность решения с тегами все же является детищем императивного мира, который плохо подходит для работы с деревьями.

VD>>>>Я же тебе только что выше писал. Это будет тормозить. Локльные фукнции разбираются только в рамках метода в котором они объявлены. Если кода в таком методе будет много или будет много перегрузок, то тормоза неизбежны.

Z>Да немного кода во вьюхах, совсем немного.

Не вижу этого! Я вижу что ты пока приводишь детские примеры. А когда ты захочешь отобразить сложную форму с вложенными подформами (скажем закладками), в которых отображается много данных, то твои вьюхи превратятся к бесформенную кашу которую трудно будет обработать.

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

VD>>Причем тут Решапрер? Я писал код о котором говорю. И точно знаю его плюсы и минусы.

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

Речь не идет о чем-то огромном. Тормоза будут на весьма не большом объеме. Средняя функция работает приемлемо, но пата экранов эмуляции HTML-я уже могут нагнуть редактор. Особенно если там будет много перегруженных функций (в этом случае тормоза будут еще раньше).

VD>>И вообще, зачем ты с кем-то советуешься если ни одна чужая мысль тебя заранее не интересует?

Z>Как тебе сказать У меня возникло 2 направления для получения хорошего результата с минимальными затратами.

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

Z>Оба неидеальны так как требуют некоторой допилки IDE или компилятора что возможно только при консультации с тобой.

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

Хочешь заняться реализацией поддержки согращенного синтаксиса модулей? ОК, но сразу приготовься к тому, что там тоже придется написать определенный объем кода.

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

У меня просто нет этого времени. Нужно править баги в компиляторе и интеграции. За меня этого никто не сделает.

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

Что-то у тебя все слова других сырые. Только твои все сухие и пушистые.

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

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

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

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

Где ты тут увидел StringTemplate? У StringTemplate и того что предлагаю я общего только рекурсивный дизайн. Слова "удобный для организации контента, но очень неудобный для его написания" — это откровенное заблуждение. Код пишут намного реже нежели читают. Если код удобно организован, то его и удобно читать. А раз его удобно читать, то в нем удобно разбираться и его удобно менять. Без удобного же изменения не может быть "удобный для его написания, отладки и поддержки".

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

Это не лирика, а серьезные заблуждения с твой стороны. Очень жаль что ты даже не пытаешся понять это.
То что я вижу — это "хочу/не хочу", "нравится/не нравится" на уровне внешнего вида. Тебе не нравятся классы и методы? А кроме эстетических соображений у этого мнения есть какое-то логическое обоснование?

VD>>Да ну? Ты когда $-строки используешь сплайсы в них как голые строки рассматриваешь?

Z>Ты не поверишь, именно как сахар для String.Format, все кроме сплайсов голая строка.

А само содержимое сплайсов? Это ведь не голая строка. Так?

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

Z>Да не будет он для программиста кодом, для IDE это строка.

Ну, какая же это строка если ее разбирает и анализирует макрос?

Z>Баг реквест, что индент синтаксис не работает есть или написать?

Есть. И ответ, есть — фича не поддерживается. В прочем можешь заняться. Куда копать я покажу.

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

Z>Твой макрос будет парсить на PExpr, а строку, какой там код?

Я не понял что написано в этом предложении. Могу догадаться, что вопрос был опять о строке.
Повторяю еще раз (уже устал, так что в последний раз) строку будет парсить и анализировть макрос. Он будет выделять теги, проверять их корректность. Так же он будет выделять управляющие конструкции, проверять их корректность и формировать код. Таким образом это ни как не будет просто строкой для программиста. Ведь программист будет получать сообщения об ошибках с указанием на место ошибки. Это конечно не комплит тегов, но все же.

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

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

Z>Пятый раз повторяю, что выносить можно.

Да ну? И как, если методы ты не предусмотрел? В локальные функции?

VD>>Что же мешает обсуждению столь не очевидного дизайна?

Z>Это очевидный дизайн. Он объявлялся с самого начала, все, для чего достаточно соглашений, будет оформлено на соглашениях.

Согласись, "очевидный" и "объявлялся с самого начала" — это не одно и тоже. К тому же кто может понять, что ты там задумывал? Из роадмапа можно только общие идеи уловить.

VD>>В БЛтулкит я могу задать любой имя атрибутом. Почему это не использовать?

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

Опять несвязанные высказывания. Как из "Приложение должно быть предсказуемым." следует, что нельзя давать алиасы таблицам? Они описаны. Ладно. Нет, так нет. Но плюсом это точно не назовешь.

VD>>А если в БД у меня таблицы названы в стиле ИМЯ_МОЕЙ_ТАБЛИЦЫ, а в коде я хочу иметь имена в виде ИмяМоейТаблицы?

Z>Это планируется решать на уровне настроек драйвера БД.

Хм. А это будет предсказуемо?

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

Ну, а как с тем же интеллисенсом? Если исходник не в проекте, то его точно не будет.

VD>>Самый наргуженный сайт имеет сотри параллельных запросов (ну тысячи в крайних случаях). Это несколько десятков метров памяти, а то и метров. Нужна эта память будет на пару миллисекунд. Она даже не будет попадать в первое поколения (в 99% случаев сдыхая в нулевом).

Z>А ты предлагаешь запросу выхватить мегабайты, которые лягут в LOH.

Мы создаем тысячи мелких объектов. Почему они должны лечь в LOH?

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

VD>>Я не знаком со спарком. Уверен, что хамл как раз таки рекурсивен. Возможно спарк тоже рекурсивен. Но ты пытаешься создать их не рекурсивные версии. И это очень печально.

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

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

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

Я не обижаюсь. Просто не на что. Я пытаюсь донести простые мысли которые мне кажутся очевидными. Но у меня не получается.

Z>АСТ тогда зачем?

Для тех кому нужен контроль и гибкая обработка. Такое АСТ можно будет потом проверить и трансформировать (аналогично XSLT).

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

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

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

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

VD>Ты их усердно отметаешь.

Что конкретно я отмел? Я привожу доступные для легкого понимания примеры — ты называешь их детскими и делаешь неверные выводы из за своего непонимания технологии (код реальных вьюх не превращается в спагетти). А сам не привел ни одного своего примера. Пока будут только убеждения о том как это все круто эта дискуссия не имеет смысла.

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

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

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

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

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

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

Z>Что конкретно я отмел?

Соображения о контроле во время компиляции и разработки. Контролем будет заниматься система типов. Она тебе просто не даст поместить, скажем, <tr> в <li>.

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

Z>Именно, что в спарке почти все из того, что ты тут расписал реализовано.

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

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

А зачем "бы"? Объясни. Только на надо этих "на практике".

Z>Но ты не читаешь все равно, а отвечаешь одним выражением — "это все непростительный косяк дизайна".

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

Z>Вот честно, сколько проектов под MVC ты написал?

Мы пенесометрией решили заняться?

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

Мне не надо понимать "почему они должны". Я с этим и так согласен. Я не вижу как этого достичь.

Но я вижу что из совершенно неизвестных соображений ты упорно отказываешься от очень простой идеи — разбить рендеринг на отдельные функции.

Z>Еще раз внимательно прочитай: Из всего что ты предложил — спарку не хватает только вьюх высшего порядка. Я думаю над их добавлением.

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

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

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

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

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

Не спорю. Если делать все по совести, то объем работы не мал. Хотя конкретно объем работы по движку редеренга не так уж велик как ты описываешь.

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

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

Z>Сейчас ты называешь поддержку индент синтаксиса низкоприоритетной,

Ну, почему же сейчас? Так было изначально.

Z>а завтра поддержку твоего языка,

Какого еще моего языка?

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

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

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

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

VD>Соображения о контроле во время компиляции и разработки. Контролем будет заниматься система типов. Она тебе просто не даст поместить, скажем, <tr> в <li>.

Отмел потому, что таком контролю можно научить парсер спарка, а сам спарк уже умеет компилить вьюхи в компайл тайме.

VD>Ты сам себе противоречишь. Только что у тебя Спарк писал стрим, и вдруг "в спарке почти все из того, что ты тут расписал реализовано".

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

VD>А зачем "бы"? Объясни. Только на надо этих "на практике".

Ок. Лейаут, позволяет не дублировать в каждой вьюхе структуру страницы. Он один на кучу вьюх, а то и на весь сайт. Он не должен быть рекурсивным т.к. <html> внутри <html> не валиден. И не может быть использован как точка входа для рендера страницы (в твоем дизайне с этим не очень понятно), поскольку один для всех.

Поэтому появляется точка входа — вьюха. Используется для рендера конкретной страницы. Именно ей передает сформированный кусок данных контроллер.

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

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

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

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

Чтобы читали. И думали действительно ли там есть приписываемый косяк.

Z>>Вот честно, сколько проектов под MVC ты написал?
VD>Мы пенесометрией решили заняться?

Нет. Хочу понять твой язык theorycraft или базируется на набитых шишках.

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

Странно, что ты не видишь, что спарк как раз это реализует.

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

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

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

VD>Что-то ты на меня наговариваешь. Если я что-то пообещал, то сделаю.

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

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

Я все равно не потяну это один.

VD>Какого еще моего языка?

Ты же предлагаешь свой язык для написания вьюх.

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

Взаимно трачу время на то, чтобы объяснить, что не все так плохо как тебе кажется.