Веб фрэймворк для Nemerle - Nemerle

Все привет, особенно Ziaw.

Особенно потому, что это идея в первую очередь адресуется ему как создателю НРельсов.

Я тут посмотрел Lift (фиговенький передов книги по нему) и нашел его идеи по рендеренгу (точнее его подход к реализации паттерна MVC) вполне милым, логичным для ФЯ и (что самое важное) легко реализуемым на базе макросов немерла.

В качестве средства упрощения работы с БД можно использовать Nemerle on rails созданный Ziaw. Рельсы по всей видимости нужно еще доводить до ума, но как основа они точно потянут.

Остается только движок рендеренга HTML/XML-я и JSON. JSON опять же уже смастерил Ziaw.

Так вот чтобы получить действительно законченные Nemerle on rails нужно смастерить движок рендеренга HTML/XML.

Предлагаю повторить Lift (естественно, с учетом особенностей немерла).

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

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:lift="http://liftweb.net/"> 
 <head> 
   <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> 
   <meta name="description" content="" /> 
   <meta name="keywords" content="" />
   <title>demo.helloworld:helloworld:1.0-SNAPSHOT</title> 
   <script id="jquery" src="/classpath/jquery.js" type="text/javascript"></script> 
 </head> 

 <body> 
   <lift:bind name="content" /> 
   <lift:Menu.builder /> 
   <lift:msgs/>
 </body> 

</html>

Собственно вся идея заключается в размещении тегов-заместителей (плэйсхолдеров) вроде <lift:Menu.builder /> для указанию движку рендеренга мест в которые нужно вставить динамический контент.

В теге <lift:Menu.builder /> значение Menu.builder — это имя метода представления который и генерирует динамический контент. Другими словами это что-то вроде активных тегов JSP или Руби. Не трудно развить эту идею и передавать параметры таким тегам (в виде атрибутов тегов).

Метод вызываемый таким образом должен всего лишь возвращать XML в определенном форммте. Для нас это будет формат XElement (т.е. LinqToXml).

Этот метод волен пользоваться любыми средствами формирования тегов, но основным средством будет Nemerle.Xml — DSL позволяющий придать человеческое лицо LinqToXml-ю.

Очень важной особенностью таких тегов является то, что они могут появляться не только в шаблонах, но и том ХМЛ-е который возвращается методами заполняющими плэйсхолдеры (вроде упомянутого Menu.builder). Принцип действия очень похож на раскрытие макросов немерла. Движок раскрывает одни плэйсхолдер подставляя вместо него содержимое сгенерированное указанным методом. Если в содержимом так же появляются плэйсхолдеры, то движок так же происходит их раскрытие. И так до тех пор пока в результате не получится ХМЛ не содержащий ни одного активного тега.

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

Кто-то может спросить — "А где же здесь контролер?" — и я отвечу — здесь его нет и здесь он не нужен. Но это не значит, что его не будет совсем. Контроллер остается для: формирования сложных структур данных (тех что трудно получить одним запросом), для кэширования, для организации навигации и т.п. В случае когда контроллер формирует сложные наборы данных имеет смысл использовать модель Model <-> View Model, т.е. контроллер перепаковывает данные в View Model и далее во View используется уже эта копия. Это позволит формализовать трансформацию данных модели в данные которые удобно отображать пользователю.

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

VD>Кто-то может спросить — "А где же здесь контролер?" — и я отвечу — здесь его нет и здесь он не нужен. Но это не значит, что его не будет совсем. Контроллер остается для: формирования сложных структур данных (тех что трудно получить одним запросом), для кэширования, для организации навигации и т.п. В случае когда контроллер формирует сложные наборы данных имеет смысл использовать модель Model <-> View Model, т.е. контроллер перепаковывает данные в View Model и далее во View используется уже эта копия. Это позволит формализовать трансформацию данных модели в данные которые удобно отображать пользователю.

Все это подозрительно напоминает АСН.НЕТ веб формс, хотя там и более простая схема. Ну, собственно, и проблемы там будут точно такие же. Что будет представлять собой Menu.builder? Закрытый метод, блек бокс. А это-то и плохо. Когда завтра нужно будет сделать такое же меню, но "с перламутровыми пуговицами", то, не имея возможности изменить код Menu.builder, этот самый Menu.builder будет просто выбрасываться и переделываться ручками.

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

VD>Я тут посмотрел Lift (фиговенький передов книги по нему) и нашел его идеи по рендеренгу (точнее его подход к реализации паттерна MVC) вполне милым, логичным для ФЯ и (что самое важное) легко реализуемым на базе макросов немерла.

Его подход имеет каноническое название — MVP с активной view. Хотя они его преподносят как революционный view first

VD>Так вот чтобы получить действительно законченные Nemerle on rails нужно смастерить движок рендеренга HTML/XML.

Тут я промолчу.

У нрельс есть проблемы и есть некоторые вещи, которые я бы хотел добавить, но движок рендеринга от лифта оставит от рельс только DSL миграций

Ибо MVC там уже будет лишней сущностью и все, что написано для него пойдет лесом.

VD>Предлагаю повторить Lift (естественно, с учетом особенностей немерла).

VD>В теге <lift:Menu.builder /> значение Menu.builder — это имя метода представления который и генерирует динамический контент. Другими словами это что-то вроде активных тегов JSP или Руби. Не трудно развить эту идею и передавать параметры таким тегам (в виде атрибутов тегов).

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

VD>Метод вызываемый таким образом должен всего лишь возвращать XML в определенном форммте. Для нас это будет формат XElement (т.е. LinqToXml).
VD>Этот метод волен пользоваться любыми средствами формирования тегов, но основным средством будет Nemerle.Xml — DSL позволяющий придать человеческое лицо LinqToXml-ю.
VD>Очень важной особенностью таких тегов является то, что они могут появляться не только в шаблонах, но и том ХМЛ-е который возвращается методами заполняющими плэйсхолдеры (вроде упомянутого Menu.builder). Принцип действия очень похож на раскрытие макросов немерла. Движок раскрывает одни плэйсхолдер подставляя вместо него содержимое сгенерированное указанным методом. Если в содержимом так же появляются плэйсхолдеры, то движок так же происходит их раскрытие. И так до тех пор пока в результате не получится ХМЛ не содержащий ни одного активного тега.

VD>Собственно последняя особенность и определяет рекурсивный дизайн и устраняет необходимость дублирования кода.

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

VD>Кто-то может спросить — "А где же здесь контролер?" — и я отвечу — здесь его нет и здесь он не нужен. Но это не значит, что его не будет совсем.

Контроллера нет, потому, что это MVP. Вместо него появилась куча презентеров.

VD>Контроллер остается для: формирования сложных структур данных (тех что трудно получить одним запросом), для кэширования, для организации навигации и т.п. В случае когда контроллер формирует сложные наборы данных имеет смысл использовать модель Model <-> View Model, т.е. контроллер перепаковывает данные в View Model и далее во View используется уже эта копия. Это позволит формализовать трансформацию данных модели в данные которые удобно отображать пользователю.

Для кэширования и навигации используются фильтры и АОП. Контроллерами называть это как-то странно.

Я считаю, что MVP неудачно вписывается в веб, настолько, насколько MVC неудобен в десктопе.

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

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

VD>>Кто-то может спросить — "А где же здесь контролер?" — и я отвечу — здесь его нет и здесь он не нужен. Но это не значит, что его не будет совсем. Контроллер остается для: формирования сложных структур данных (тех что трудно получить одним запросом), для кэширования, для организации навигации и т.п. В случае когда контроллер формирует сложные наборы данных имеет смысл использовать модель Model <-> View Model, т.е. контроллер перепаковывает данные в View Model и далее во View используется уже эта копия. Это позволит формализовать трансформацию данных модели в данные которые удобно отображать пользователю.

ВВ>Все это подозрительно напоминает АСН.НЕТ веб формс, хотя там и более простая схема. Ну, собственно, и проблемы там будут точно такие же. Что будет представлять собой Menu.builder? Закрытый метод, блек бокс. А это-то и плохо. Когда завтра нужно будет сделать такое же меню, но "с перламутровыми пуговицами", то, не имея возможности изменить код Menu.builder, этот самый Menu.builder будет просто выбрасываться и переделываться ручками.

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

2Влад: я настоятельно рекомендую взять для примера html (например отсюда) и произвести тест производительности. Построение dom по нему, модификация пары элементов через linq to xml и вывод в стрим. Учтем то, что это еще довольно скромный html. Если займет больше 5ms — в топку.

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

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

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

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

А "классическая" инкапсуляция генерации ХТМЛ-я на манер веб-формс — ИМХО зло в квадрате.

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

Очень рекомендую посмотреть вот на эту штуку
http://knockoutjs.com/
Идеология реактивный MVVM.
Собственно это идеальный подход к ГУИ вообще и к веб ГУИ в частности.

Сделав такой ДСЛ на немерле все станет сщвсем просто и статически типизированно.

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

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

ВВ>Все это подозрительно напоминает АСН.НЕТ веб формс, хотя там и более простая схема. Ну, собственно, и проблемы там будут точно такие же.

Во-первых, как-то не очень похоже. Во-вторых, в АСН.НЕТ есть только одна проблема. Они пытаются эмулировать виндовые интерактивные формы. При этом делят состояние между клиентом и сервером. В результате все портит вью-стэйт.

Другого ничего плохого я не вижу.

ВВ>Что будет представлять собой Menu.builder? Закрытый метод, блек бокс.

Что значит закрытый? Функция будет. Банальная функция.

ВВ>А это-то и плохо. Когда завтра нужно будет сделать такое же меню, но "с перламутровыми пуговицами", то, не имея возможности изменить код Menu.builder, этот самый Menu.builder будет просто выбрасываться и переделываться ручками.

Бред какой-то. Это значит я уже не могу сделать универсальную функцию?

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

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

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

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

Все нормально взлетает. Дом (в виде XLinq) шуршит с очень приличной скоростью.

Z>2Влад: я настоятельно рекомендую взять для примера html (например отсюда) и произвести тест производительности. Построение dom по нему, модификация пары элементов через linq to xml и вывод в стрим. Учтем то, что это еще довольно скромный html. Если займет больше 5ms — в топку.

Да что там тестировать. Это будут единицы миллисекунд. Чтение с диска займет больше времени.

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

Z>2Влад: я настоятельно рекомендую взять для примера html (например отсюда) и произвести тест производительности. Построение dom по нему, модификация пары элементов через linq to xml и вывод в стрим. Учтем то, что это еще довольно скромный html. Если займет больше 5ms — в топку.

Ты заставил убить меня пол часа на причесывание этой долбанной страницы под ХМЛ

.

Короче, вот такой тест:

    repeat (4)
    {
      def timer = Diagnostics.Stopwatch.StartNew();
      def x = XElement.Load(@"c:\TEMP\test.xml");
      WriteLine($<#img tags count: $(x.Descendants("img").Count())#>);
      WriteLine(timer.Elapsed);
    }

Дает следующие результаты:

img tags count: 53
00:00:00.0020369
img tags count: 53
00:00:00.0009853
img tags count: 53
00:00:00.0010329
img tags count: 53
00:00:00.0009575

Это в дебаге на 3 Ггц Кор Дуо
Плюс сюда входит считывание данных с диска (логическое чтение).
Могу выложить и ХМЛ. Он в юникоде занимает 98 КБ.

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

ВВ>С ХСЛТ такая схема хорошо работает. Там Menu.builder будет набором достаточно гранулярных шаблонов, и мне достаточно будет лишь снаружи, не меняя самого билдера, перекрыть какой-то один шаблон. Возможно, есть другие шаблонизаторы, позволяющие подобное — тут я не знаю. Но мне кажется, думать надо скорее в таком направлении.

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

Можно даже аналог ХСЛТ-шного матча сделать, так чтобы функции вызывались в зависимости от контента.

Ты Nemerle.Xml вил?

    def makeClassInfoPage(cls : Type) : void
    {
      def props = cls.GetProperties();
      def events = cls.GetEvents();
      def title = $"Класс <$(cls.Name)>";
      def html = xml <# 
        <html>
          <head>
            <title>$title</title>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
            <link rel="stylesheet" href="http://rsdn.ru/css/article.css" type="text/css" />
          </head>
          <body marginwidth="20" marginheight="20">
            <H1>$title</H1>
            
            <H2 $unless (props.IsEmpty())>Свойства</H2>
            <ol $unless (props.IsEmpty())>
              <li $foreach (p in props)>$(p.Name) : $(p.PropertyType)</li>
            </ol>
            
            <H2 $unless (events.IsEmpty())>События</H2>
            <ol $unless (events.IsEmpty())>
              <li $foreach (e in events)>$(e.Name) : $(e.EventHandlerType)</li>
            </ol>
          </body>
        </html>
   #>;
   
      def path = IO.Path.ChangeExtension(IO.Path.GetTempFileName(), "html");
      IO.File.WriteAllText(path, html.ToString());
      _ = Diagnostics.Process.Start(path);
    }
    
    makeClassInfoPage(typeof(XAttribute));
    makeClassInfoPage(typeof(TestClass));

ВВ>А "классическая" инкапсуляция генерации ХТМЛ-я на манер веб-формс — ИМХО зло в квадрате.

Откровенно говоря не вижу в чем это зло и чем оно отличается от того же ХСЛТ.

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

VD>Все привет, особенно Ziaw.

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

VD>Я тут посмотрел Lift (фиговенький передов книги по нему) и нашел его идеи по рендеренгу (точнее его подход к реализации паттерна MVC) вполне милым, логичным для ФЯ и (что самое важное) легко реализуемым на базе макросов немерла.

VD>В качестве средства упрощения работы с БД можно использовать Nemerle on rails созданный Ziaw. Рельсы по всей видимости нужно еще доводить до ума, но как основа они точно потянут.

VD>Остается только движок рендеренга HTML/XML-я и JSON. JSON опять же уже смастерил Ziaw.

VD>Так вот чтобы получить действительно законченные Nemerle on rails нужно смастерить движок рендеренга HTML/XML.

VD>Предлагаю повторить Lift (естественно, с учетом особенностей немерла).

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

VD><html xmlns="http://www.w3.org/1999/xhtml" xmlns:lift="http://liftweb.net/"> 
VD> <head> 
VD>   <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> 
VD>   <meta name="description" content="" /> 
VD>   <meta name="keywords" content="" />
VD>   <title>demo.helloworld:helloworld:1.0-SNAPSHOT</title> 
VD>   <script id="jquery" src="/classpath/jquery.js" type="text/javascript"></script> 
VD> </head> 

VD> <body> 
VD>   <lift:bind name="content" /> 
VD>   <lift:Menu.builder /> 
VD>   <lift:msgs/>
VD> </body> 

VD></html>
VD>

А чем это отличается он mvcшного
<% Html.RenderAction<HomeController>(c => c.Menu()) %>
?

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

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

Не надо так овреквоить, плиз.

D>А чем это отличается он mvcшного
D><% Html.RenderAction<HomeController>(c => c.Menu()) %>
D>?

Очевидно вот этим "tml.RenderAction<HomeController>(c => "

Это все не нужно.

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

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

Z>>2Влад: я настоятельно рекомендую взять для примера html (например отсюда) и произвести тест производительности. Построение dom по нему, модификация пары элементов через linq to xml и вывод в стрим. Учтем то, что это еще довольно скромный html. Если займет больше 5ms — в топку.

VD>Ты заставил убить меня пол часа на причесывание этой долбанной страницы под ХМЛ

.

Ну так допили до нужного уровня, например засунь все img в <div class='img'> и выведи результат в memorystream. Только тогда все получится похоже на правду. Для сравнения, подобная вьюха на руби будет рендериться 3-5ms.

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

VD>Очевидно вот этим "tml.RenderAction<HomeController>(c => "

VD>Это все не нужно.

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

<% H(c => c.Menu()) %>
Если прикрутить Т4, можно сократить до
<% Menu() %>

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

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

VD>

VD>    def makeClassInfoPage(cls : Type) : void
VD>    {
VD>      def props = cls.GetProperties();
VD>      def events = cls.GetEvents();
VD>      def title = $"Класс <$(cls.Name)>";
VD>      def html = xml <# 
VD>        <html>
VD>          <head>
VD>            <title>$title</title>
VD>            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> 
VD>            <link rel="stylesheet" href="http://rsdn.ru/css/article.css" type="text/css" />
VD>          </head>
VD>          <body marginwidth="20" marginheight="20">
VD>            <H1>$title</H1>
            
VD>            <H2 $unless (props.IsEmpty())>Свойства</H2>
VD>            <ol $unless (props.IsEmpty())>
VD>              <li $foreach (p in props)>$(p.Name) : $(p.PropertyType)</li>
VD>            </ol>
            
VD>            <H2 $unless (events.IsEmpty())>События</H2>
VD>            <ol $unless (events.IsEmpty())>
VD>              <li $foreach (e in events)>$(e.Name) : $(e.EventHandlerType)</li>
VD>            </ol>
VD>          </body>
VD>        </html>
VD>   #>;
   
VD>      def path = IO.Path.ChangeExtension(IO.Path.GetTempFileName(), "html");
VD>      IO.File.WriteAllText(path, html.ToString());
VD>      _ = Diagnostics.Process.Start(path);
VD>    }
    
VD>    makeClassInfoPage(typeof(XAttribute));
VD>    makeClassInfoPage(typeof(TestClass));
VD>

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

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

ВВ>>Все это подозрительно напоминает АСН.НЕТ веб формс, хотя там и более простая схема. Ну, собственно, и проблемы там будут точно такие же.

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

К сожалению, не только. Плоха сама идея инкапсуляции генерации ХТМЛ-я. Она просто не работает как нужно.

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

Ты говоришь с позиций теоретика. На словах-то все хорошо, да. В реальности же такой подход не заводится. Ибо это по сути тот же веб-контрол. Который скрывает всю работу с ХТМЛ и предоставляет явные точки для ее настройки. Да, да, те же параметры у тегов. Это означает, что если разработчик не предусмотрел какой-то из вариантов расширения, то весь его "контрол" идет лесом. Ну вот предположим, что мне нужно переопределить логику генерации какого-нибудь грида и мержить некоторые столбцы или же строки запрятать в tbody и динамически их прятать/показывать.

Всех возможных сценариев использования не продумаешь.

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

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

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

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

Нужен подход, который будет вообще не давать так писать.

ВВ>>А "классическая" инкапсуляция генерации ХТМЛ-я на манер веб-формс — ИМХО зло в квадрате.
VD>Откровенно говоря не вижу в чем это зло и чем оно отличается от того же ХСЛТ.

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

От:	VladD2	www.nemerle.org
Дата:	13.02.11 18:48
Оценка:

	От:	Воронков Василий
	Дата:	13.02.11 19:25
	Оценка:	+1

	От:	Ziaw
	Дата:	13.02.11 19:49
	Оценка:

	От:	Ziaw
	Дата:	13.02.11 20:03
	Оценка:

	От:	Воронков Василий
	Дата:	13.02.11 20:19
	Оценка:	+1

	От:	dotneter
	Дата:	14.02.11 04:56
	Оценка:

	От:	dotneter
	Дата:	14.02.11 06:12
	Оценка: