Re[7]: Веб фрэймворк для 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>Откровенно говоря не вижу в чем это зло и чем оно отличается от того же ХСЛТ.

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

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

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

D><% H(c => c.Menu()) %>

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

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

Зачем нам убогий T4? У нас есть макросы. С ними мы можем тупо написать:

<ИмяМетода/>

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

Z>Ну так допили до нужного уровня, например засунь все img в <div class='img'> и выведи результат в memorystream.

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

Z>Только тогда все получится похоже на правду. Для сравнения, подобная вьюха на руби будет рендериться 3-5ms.

Откуда данные?

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

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

Какая связь? Я показал действие литералов. Уж извини что пример есть именно такой.

Я просто показал Воронкову, что есть аналогичный лифтовскому механизм.

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

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

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

D>><% H(c => c.Menu()) %>

VD>Грязи меньше, но она есть.

VD>И есть возможность загнать в ХТМЛ необрабтанную строку. А это потенциальная уязвимость.
<lift:Menu.builder /> а тут нельзя загнать?
VD>Так зачем нам нужен этот кривой подход? Что он дает?
Так я и интересуюсь чем он кривой, и чем лифтовский кординально он него отличается.

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

VD>Зачем нам убогий T4? У нас есть макросы. С ними мы можем тупо написать:
VD>

VD><ИмяМетода/>
VD>

Интелисенс, рефакторинг и навигация будут работать?
Вообще я пытаюсь сравнить mvc c lift.

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

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

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

Архитектура мешает и традиции. Императив он и есть императив.

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

Если будет делать ламер, то конечно. Но тогда надо признать, что это проблема не фрэймворка, а самого метода инкапсуляции кода в функциях. Вот в Дельфи и Васике тоже часто весь код в одном разработчике лежит. Но это же не проблема Дельфи, Васика или даже всего RAD-подхода? Это проблема программиста. Если он захочет, то все средства декомпозиции в его распоряжении.

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

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

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

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

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

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

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

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

Это общие слова. Хотелось бы получить какие-то аргументы.

ВВ>Ты говоришь с позиций теоретика. На словах-то все хорошо, да.

А ты с позиции скептика у которого все плохо что не им писано (NIH).

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

Это если у вас есть именно что веб-контрол. Я долго объяснял Ziaw-у, что контролы эти порочны.
И дело тут в том, что они не предусматривают рекурсивности в дизайне.

ВВ>Ну вот предположим, что мне нужно переопределить логику генерации какого-нибудь грида и мержить некоторые столбцы или же строки запрятать в tbody и динамически их прятать/показывать.

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

Более того с движком рендеренга это будет очень не сложно.

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

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

И что ты предлагаешь в замен?

ВВ>Ты пойми, люди уже пытались сделать так, как ты говоришь. И это не взлетело.

Значит то что Lift взлетел — это ложь авторов?

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

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

В конце концов какая разница где будет логика генерации ХМЛ-я в внутри шаблона, или в отдельном методе? Что это изменит для этой самой генерации?

А вот качество всего приложения это меняет сильно. Код размазанный оп текстовым шаблонам — это пипец. Это АСП 1.0 в худших его проявлениях.

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

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

Дык это главное что в нем есть.

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

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

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

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

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

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

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

В общем, Спарк — это чистый шлак. АСП 1.0 с улученым синтаксисом.

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

Да какая разница как это называть контроллер или презентер? Это все вариации на тему MVC.

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

Если нужен АОП, значит вы на неверном пути

. А как не называй, то управляющий код будет по терминологии MVC контроллером.

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

Ты сейчас сказал дикую глупость. Все известные мне ГУИ-библиотеки для десктопа были вариациями на тему MVC. Я еще могу согласиться с Вольфхаундом, что модель для любого ЮИ модель MVVM подходит лучше чем любые другие вариации MVC. Но мы то в общем-то сейчас говорим о рендеренге ХТМЛ-я. Тут даже и говорить не о чем.

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

D><lift:Menu.builder /> а тут нельзя загнать?

Только если очень намеренно. Menu.builder вернет AST ХМЛ-я. В него просто нельзя без приседаний вставить плоский текст.
В этом одна из прелестей подобного подхода.
Проблема конечно в том, что страницу придется представлять в виде AST (DOM-а, если так привычнее). Но это довольно шустро.

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

У него несколько недостатков. Основные — это текстоориентированность. Это не позволяет защититься от случайной вставки уязвимостей. Второй — это необходимость перевешивать код и шаблоны.

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

VD>>Зачем нам убогий T4? У нас есть макросы. С ними мы можем тупо написать:
VD>>

VD>><ИмяМетода/>
VD>>

D>Интелисенс, рефакторинг и навигация будут работать?

А в Т4? Для текстовых шаблонов интелисенс придется делать отдельно. Но он там не очень то нужен. Ведь кода в них не будет. А чтобы вбить имена методов особого ума не надо. Макрос же проверит их корреткность и если что укажет где мы ошиблись. Так что ошибок по забывчивости не будет.

D>Вообще я пытаюсь сравнить mvc c lift.

А lift и реализует паттерн MVC. Если ты говоришь о ASP.NET MVC, то основная разница в подходах генерации ХТМЛ-я. Лифт предлагает функциональный подход и шаблоны не содержащие код (только вызовы методов завуалированные под теги), а АСП МВЦ предлагает АСП-шаблоны с кодом вперемешку. При этом такой подход не очень удобно для функционального исполнения и провоцирует писать много кода в шаблонах.

Здравствуйте, VladD2, Вы писали:
VD>А в Т4?
Да. С незначительными погрешностями.
VD>Для текстовых шаблонов интелисенс придется делать отдельно. Но он там не очень то нужен. Ведь кода в них не будет. А чтобы вбить имена методов особого ума не надо. Макрос же проверит их корреткность и если что укажет где мы ошиблись. Так что ошибок по забывчивости не будет.

D>>Вообще я пытаюсь сравнить mvc c lift.

VD>А lift и реализует паттерн MVC. Если ты говоришь о ASP.NET MVC, то основная разница в подходах генерации ХТМЛ-я. Лифт предлагает функциональный подход и шаблоны не содержащие код (только вызовы методов завуалированные под теги), а АСП МВЦ предлагает АСП-шаблоны с кодом вперемешку. При этом такой подход не очень удобно для функционального исполнения и провоцирует писать много кода в шаблонах.
Идея понятно, не понятны выводы.
С одной стороны где то же у них, все равно должно быть совмещение html и кода, с другой стороны в Razor тоже можно запихивать в методы.

@helper DefaultList(string[] list){
<ul>
@foreach (string s in list) {
<li>@s</li>
}
</ul>
}

@DefaultList(new [] {"foo", "bar"}))

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

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

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

Z>>Ну так допили до нужного уровня, например засунь все img в <div class='img'> и выведи результат в memorystream.

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

Z>>Только тогда все получится похоже на правду. Для сравнения, подобная вьюха на руби будет рендериться 3-5ms.

VD>Откуда данные?

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

Это development(дебаг, комп старенький Core 2 Duo 2.4):

Started GET "/" for 127.0.0.1 at Tue Feb 15 00:05:26 +0700 2011
  Processing by TestController#show as HTML
Rendered test/show.html.erb (2.4ms)
Completed 200 OK in 5ms (Views: 4.4ms | ActiveRecord: 0.0ms)

Это production(релиз)

Started GET "/" for 127.0.0.1 at Tue Feb 15 00:06:59 +0700 2011
  Processing by TestController#show as */*
Rendered test/show.html.erb (0.1ms)
Completed 200 OK in 1ms (Views: 0.6ms | ActiveRecord: 0.0ms)

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

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

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

VD>Дык это главное что в нем есть.

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

VD>MVC (паттерн) будет там по любому. Лишней сущностью является только его реализация сделанная для C# силами которого такое не сделать в принципе. Вот и делают внешний ДСЛ, а потом огребают по полной, так как не могут его нормально совместить с остальным кодом. Начинается копипэст и твои приседания чтобы от него избавиться. Это следствие кривой архитектуры. Убери лишние звено и проблем совмещения не будет как класс.

Имелся в виду ASP.NET MVC. Его в твое решении придется выкинуть.

VD>Да какая разница как это называть контроллер или презентер? Это все вариации на тему MVC.

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

VD>Если нужен АОП, значит вы на неверном пути

. А как не называй, то управляющий код будет по терминологии MVC контроллером.

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

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

VD>Ты сейчас сказал дикую глупость. Все известные мне ГУИ-библиотеки для десктопа были вариациями на тему MVC. Я еще могу согласиться с Вольфхаундом, что модель для любого ЮИ модель MVVM подходит лучше чем любые другие вариации MVC. Но мы то в общем-то сейчас говорим о рендеренге ХТМЛ-я. Тут даже и говорить не о чем.

MVP и MVVM это не MVC, это паттерны родившиеся из MVC. Вобщем в очередной раз ты демонстрируешь безапеляционность в тех вопросах, в которых разбираешься на уровне "читал статью, там все просто". Как евангелисту немерла это качество тебе необходимо конечно, но зачем так настойчиво проталкивать решения родившиеся без практики? Решения, которые аргументированно не нравятся людям в теме?

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

D>С одной стороны где то же у них, все равно должно быть совмещение html и кода, с другой стороны в Razor тоже можно запихивать в методы.

Разор более продвинутый в этом плане. Но тоже далеко не все ОК в нем. Тут же народ держится за совсем гнилую архитектуру.

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

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

Ну, да я что-то потестил (сам пока не понял что) и сделал далеко идущие выводы.

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

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

Ясно одно. Скорости хватает выше крыши. Одна миллисекунда при чтении данных с диска это более чем достаточно для 99% применений.

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

Z>Влад! Я тебя не узнаю, ты же мне, твердил, что миграции это шлак.

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

Z>И что они никому не нужны,

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

Z>но раз я упертый баран и не хочу понимать простых вещей, то могу писать, главное, чтобы без них можно было работать. И что же теперь?

Вообще не понял сказанного.

Z>Имелся в виду ASP.NET MVC. Его в твое решении придется выкинуть.

Дык, а он и не нужен. Это подпорка для C# в котором без внешнего кода нужную функциональность не реализовать.
Но у нас то есть макры! Ими делается любая реализация и делается в сто раз проще.

Z>Есть общепринятый подход в вебе который называется MVC, таких фреймворков полно. Не вводи своей терминологии.

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

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

VD>>Ты сейчас сказал дикую глупость. Все известные мне ГУИ-библиотеки для десктопа были вариациями на тему MVC. Я еще могу согласиться с Вольфхаундом, что для любого ЮИ модель MVVM подходит лучше чем любые другие вариации MVC. Но мы то в общем-то сейчас говорим о рендеренге ХТМЛ-я. Тут даже и говорить не о чем.

Z>MVP и MVVM это не MVC,

Ну, конечно! Ты читал основополагающие работы по MVC? Там дается очень образное определение и говорится о возможных отклонениях.7

Z>это паттерны родившиеся из MVC.

MVC — это не предопределенный дизайн реализации, а всего лишь общая идея отделения информации от ее представления.

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

Ну, да полил грязь оппонента и вроде как стал прав в собственных глазах. У тебя все споры в которых ты считаешь себя правым (а это 100% споров) заканчивается. Только по факту это слив, а не победа.

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

Не надо продолжать наезды на личность. Это не поможет тебе стать правым.

Пойми я же тоже могу по наезжать на личность. У меня большой опыт в этом вопросе. Да и вообще опыта больше. Тот же МВЦ я использовал еще 15 лет назад. И с вебом возился на заре его появления (у нас).

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

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

VD>Ну, да полил грязь оппонента и вроде как стал прав в собственных глазах. У тебя все споры в которых ты считаешь себя правым (а это 100% споров) заканчивается. Только по факту это слив, а не победа.

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

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

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

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

ВВ>>К сожалению, не только. Плоха сама идея инкапсуляции генерации ХТМЛ-я. Она просто не работает как нужно.
VD>Это общие слова. Хотелось бы получить какие-то аргументы.
ВВ>>Ты говоришь с позиций теоретика. На словах-то все хорошо, да.
VD>А ты с позиции скептика у которого все плохо что не им писано (NIH).

Нет, я говорю с позиции практика. И на практике постоянно возникает необходимость спуститься на уровень ХТМЛ-я. Поэтому все абстракции, которые строятся над ним, попросту вредны. Я не знаю, как еще это объяснить. Это веб, это UI. В любой момент может возникнуть требование типа "все хорошо, ну тут надо фон поменять на серо-буро-малиновый, а здесь черточку дорисовать". И чего мне делать с этим Menu.builder?

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

Причем тут рекурсивность? Контрол — это просто метод void Render(HtmlTextWriter). Все. Что там внутри — одному черту известно. Хочешь будет рекурсия, хочешь не рекурсия.

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

А ты, сдается мне, попросту не понимаешь, в чем *реальная* проблема у веб-форм.

ВВ>>Ну вот предположим, что мне нужно переопределить логику генерации какого-нибудь грида и мержить некоторые столбцы или же строки запрятать в tbody и динамически их прятать/показывать.
VD>Еще раз. Это не контрол. Это функция трасформации. Для генерации строк и ячеек нужно использовать такие же теги. Ну, а логика формирования должна быть доступна через параметры в виде функций высшего порядка. Пусть она берет конкретные данные, анализирует их и на их основании выдает нужный ХМЛ.

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

ВВ>>Всех возможных сценариев использования не продумаешь.
VD>И что ты предлагаешь в замен?

Я предлагаю подумать. А мега-идей у меня с прошлого раза так и не появилось. Если появятся — обязательно расскажу.

ВВ>>Ты пойми, люди уже пытались сделать так, как ты говоришь. И это не взлетело.
VD>Значит то что Lift взлетел — это ложь авторов?

Я не знаю, что в их понимании "взлетело". Я вот о Лифте вообще впервые слышу.

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

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

VD>В конце концов какая разница где будет логика генерации ХМЛ-я в внутри шаблона, или в отдельном методе? Что это изменит для этой самой генерации?
VD>А вот качество всего приложения это меняет сильно. Код размазанный оп текстовым шаблонам — это пипец. Это АСП 1.0 в худших его проявлениях.

Дело в том, что ХМТЛ, размазанный по коду на Немерле, абсолютно ничем не лучше. Ты вообще веб-страницу когда-нибудь делал сам-то? Как, ты думаешь, люди это будут писать? Прям вот так вот, с чистого листа, взял и набросал таблички, стили — раз-раз и готово? Все равно сначала все будет писать в отдельном файлике, проверяться в браузере после каждого изменения (и не в одном, а во всех целевых), а потом уже переноситься в код. И вот когда держишь в голове такой юзкейс крутотень от ХМЛ-литералов как-то исчезает.

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

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

VD>>Ну, да полил грязь оппонента и вроде как стал прав в собственных глазах. У тебя все споры в которых ты считаешь себя правым (а это 100% споров) заканчивается. Только по факту это слив, а не победа.

Z>Ну ты же можешь обвинять меня в некомпетентности?

Заметь, я стараюсь никого не обвинять. Бывают конечно клинические случаи, но на то они и клинические, чтобы встречаться редко.

Так что если хочешь какого-то конструктивиста, то советую не опускаться до наездов на личность оппонента.

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

WH>Сделав такой ДСЛ на немерле все станет сщвсем просто и статически типизированно.
Как это может выглядеть.
За основу я буду брать примеры из knockoutjs и переводить их свой ДСЛ.

Hello World example

view HelloView(model : HelloModel)
{
    <p>First name: <input value <-> model.firstName; /></p>
    <p>Last name: <input value <-> model.lastName; /></p>
    <h2>Hello, <span text <- model.fullName; />!</h2>
}

Оператор <-> означает двусторонний биндирг. Оператор <- односторонний. Ну и -> тоже можно завести для симметрии.
= означет одноразовое присваивание.

model HelloModel
{
    firstName : string = "Planet";
    lastName : string = "Earth";
    fullName : string <- $"$firstName $lastName";
}

Все свойства в модели "реактивны".
Свойства инициализированные через <- только для чтения.

Better list example
В данном случае я объявляю itemToAdd и selectedItems прямо во вьюхе.
Ибо это детали реализации конкретной вьюхи.
Тег def только объявляет переменную. В результирующий HTML он не попадет.
Вьюхи ессно гигееничны.

view BetterListView(model : BetterListModel)
{
    <def itemToAdd = ""; />
    <form submit -> model.addItem(itemToAdd); >
            Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
            <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
    </form>
     
    <p>Your values:</p>
    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />
     
    <div>
        <def selectedItems = []; />
        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
    </div>
}

list также реактивен.
ListItem нужен для того чтобы точно знать что удаляется в случае если у нас есть одинаковые элементы.

model BetterListModel
{
    items : list[string] = ["Fries", "Eggs Benedict", "Ham", "Cheese"];
    addItem(item : stirng) : void
    {
        items.Add(item);
    }
    remodeItems(itemsToRemove : list[ListItem[stirng]]) : void
    {
        items.RemoveAll(itemsToRemove);
    }
}

Templating example

view TemplatingView(model : PeopleModel)
{
    <div content <- PeopleView(model); />
    <label><input type = checkbox; checked <-> showRenderTimes; /> Show render times</label>
}

view PeopleView(model : PeopleModel)
{
    <h2>People</h2>
    <ul>
        <li foreach (person in model.people)>
            <div>
                $(person.name) has <span text <- $"$(children().length)">&nbsp;</span> children:
                <a click -> person.addChild(); >Add child</a>
                <span class = "renderTime"; visible <- model.showRenderTimes; >
                    (person rendered at <span text = $"$(Date().getSeconds())"; />)
                </span>
            </div>
            <div content <- ChildrenView(mode, person.children); />
        </li>
    </ul>
}

view ChildrenView(model : PeopleModel, children : list[string])
{
    <ul>
        <li foreach (name in children)>
            $name
            <span class = "renderTime"; visible <- model.showRenderTimes; >
                (child rendered at <span text = $"$(Date().getSeconds())"; />)
            </span>
        </li>
    </ul>
}

model PersonModel
{
    name : string;
    children : list[string];
    addChild() : void
    {
        children.Add("New child");
    }
}

model PeopleModel
{
    people : list[PersonModel] = [
        PersonModel("Annabelle", ["Arnie", "Anders", "Apple"]),
        PersonModel("Bertie", ["Boutros-Boutros", "Brianna", "Barbie", "Bee-bop"]),
        PersonModel("Charles", ["Cayenne", "Cleopatra"])
    ];
    showRenderTimes : bool = false;
}

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

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

WH>За основу я буду брать примеры из knockoutjs и переводить их свой ДСЛ.

Я правильно понял, что ДСЛ будет транслироваться как в клиентский код, так и в серверный?

WH>

WH>Hello World example
WH>

WH>view HelloView(model : HelloModel)
WH>{
WH>    <p>First name: <input value <-> model.firstName; /></p>
WH>    <p>Last name: <input value <-> model.lastName; /></p>
WH>    <h2>Hello, <span text <- model.fullName; />!</h2>
WH>}
WH>

Точки с запятой, я так понял, неспроста? Зачем?

WH>

WH>view BetterListView(model : BetterListModel)
WH>{
WH>    <def itemToAdd = ""; />
WH>    <form submit -> model.addItem(itemToAdd); >
WH>            Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
WH>            <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
WH>    </form>
     
WH>    <p>Your values:</p>
WH>    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />
     
WH>    <div>
WH>        <def selectedItems = []; />
WH>        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
WH>        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
WH>    </div>
WH>}
WH>

WH>list также реактивен.
WH>ListItem нужен для того чтобы точно знать что удаляется в случае если у нас есть одинаковые элементы.
WH>

WH>model BetterListModel
WH>{
WH>    items : list[string] = ["Fries", "Eggs Benedict", "Ham", "Cheese"];
WH>    addItem(item : stirng) : void
WH>    {
WH>        items.Add(item);
WH>    }
WH>    remodeItems(itemsToRemove : list[ListItem[stirng]]) : void
WH>    {
WH>        items.RemoveAll(itemsToRemove);
WH>    }
WH>}
WH>

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

WH>

WH>Templating example
WH>

WH>view TemplatingView(model : PeopleModel)
WH>{
WH>    <div content <- PeopleView(model); />
WH>    <label><input type = checkbox; checked <-> showRenderTimes; /> Show render times</label>
WH>}

WH>view PeopleView(model : PeopleModel)
WH>{
WH>    <h2>People</h2>
WH>    <ul>
WH>        <li foreach (person in model.people)>
WH>            <div>
WH>                $(person.name) has <span text <- $"$(children().length)">&nbsp;</span> children:
WH>                <a click -> person.addChild(); >Add child</a>
WH>                <span class = "renderTime"; visible <- model.showRenderTimes; >
WH>                    (person rendered at <span text = $"$(Date().getSeconds())"; />)
WH>                </span>
WH>            </div>
WH>            <div content <- ChildrenView(mode, person.children); />
WH>        </li>
WH>    </ul>
WH>}

Почему <span text <- $"$(children().length)">&nbsp;</span> А не <span>$(children().length)</span>, для реактивности? 

WH>view ChildrenView(model : PeopleModel, children : list[string])
WH>{
WH>    <ul>
WH>        <li foreach (name in children)>
WH>            $name
WH>            <span class = "renderTime"; visible <- model.showRenderTimes; >
WH>                (child rendered at <span text = $"$(Date().getSeconds())"; />)
WH>            </span>
WH>        </li>
WH>    </ul>
WH>}
WH>

WH>[c#]
WH>model PersonModel
WH>{
WH> name : string;
WH> children : list[string];
WH> addChild() : void
WH> {
WH> children.Add("New child");
WH> }
WH>}

При изменении модели, вьюха будет полностью запрошена с сервера? Как пройдет привязка PersonModel.children -> параметр children : list[string]?

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

ВВ>Нет, я говорю с позиции практика. И на практике постоянно возникает необходимость спуститься на уровень ХТМЛ-я. Поэтому все абстракции, которые строятся над ним, попросту вредны. Я не знаю, как еще это объяснить. Это веб, это UI. В любой момент может возникнуть требование типа "все хорошо, ну тут надо фон поменять на серо-буро-малиновый, а здесь черточку дорисовать". И чего мне делать с этим Menu.builder?

Дык Menu.builder это не более чем фунция. Подставь свою и вызови из нее все что нужно с нужными параметрами.
Потом в Лифте не все так уж дубово как тебе кажется:
http://www.rsdn.ru/forum/philosophy/4157485.1.aspx

ВВ>Причем тут рекурсивность?

Ну, право странно слышать это от человека который так ревностно отстаивал принципы ФП и хвалил ХСЛТ.

ВВ>Контрол — это просто метод void Render(HtmlTextWriter). Все. Что там внутри — одному черту известно. Хочешь будет рекурсия, хочешь не рекурсия.

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

ВВ>Если же ты имеешь в виду, что веб-контрол обязан возвращать ХТМЛ, а не может вернуть, скажем, набор шаблонов, то да, это разница есть.

Ага. И это очень большая разница.

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

Ага, кажется это очень точное слово.

ВВ>Все равно ты сделал веб-контрол, пусть и более навороченный.

Он тебе мерещится. Поверь. Забудь про молоток и все перестанет казаться гвоздями.

ВВ>МС уже ходила по этому пути, посмотри к чему они пришли после веб-формов — это уже *совсем* не веб-контролы.

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

ВВ>А ты, сдается мне, попросту не понимаешь, в чем *реальная* проблема у веб-форм.

Я просто понимаю, что ты сейчас борешься со своим воображением.

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

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

ВВ>Я предлагаю подумать. А мега-идей у меня с прошлого раза так и не появилось. Если появятся — обязательно расскажу.

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

ВВ>Дело в том, что ХМТЛ, размазанный по коду на Немерле, абсолютно ничем не лучше. Ты вообще веб-страницу когда-нибудь делал сам-то?

Писал. Даже на АСП без нет умудрился поработать.

ВВ>Как, ты думаешь, люди это будут писать? Прям вот так вот, с чистого листа, взял и набросал таблички, стили — раз-раз и готово? Все равно сначала все будет писать в отдельном файлике, проверяться в браузере после каждого изменения (и не в одном, а во всех целевых), а потом уже переноситься в код. И вот когда держишь в голове такой юзкейс крутотень от ХМЛ-литералов как-то исчезает.

Что все плохо я услышал. Что хорошо — нет.

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

Z>Я правильно понял, что ДСЛ будет транслироваться как в клиентский код, так и в серверный?
Да.

Z>Точки с запятой, я так понял, неспроста? Зачем?
Чтобы выражения разделять. Моожно и без них но хуже читается когда несколько выражений.
Как вариант можно для последнего выражения сделать точку с запятой не обязательной.

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

Z>Почему <span text <- $"$(children().length)"> </span> А не <span>$(children().length)</span>, для реактивности?
Можно и так. Просто я почти машинально все переписывал.
Тут есть еще над чем подумать.

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

Z>Как пройдет привязка PersonModel.children -> параметр children : list[string]?
Если будет добавлен/изменен/уделен элемент списка то вот этот код:

        <li foreach (name in children)>
            $name
            <span class = "renderTime"; visible <- model.showRenderTimes; >
                (child rendered at <span text = $"$(Date().getSeconds())"; />)
            </span>
        </li>

Отрендерит новый/перерендерит/удалит соответствующий элемент.
Если список просто переупорядочили (например отсортировали) то этот код просто передвинет куски ДОМ(если дом конечно такое позволяет я не в курсе)

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

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

WH>

WH>    <p>Your values:</p>
WH>    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />
     
WH>    <div>
WH>        <def selectedItems = []; />
WH>        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
WH>        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
WH>    </div>
WH>

Я <def selectedItems = []; /> не туда засунул.
Это конечно же должно быть перед select.

И наверное вьюхам нужно придать более XML'ный вид.
Например так:

<view BetterListView(model : BetterListModel)>
    <def itemToAdd = ""; />
    <form submit -> model.addItem(itemToAdd); >
            Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
            <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
    </form>
     
    <def selectedItems = []; />
    <p>Your values:</p>
    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />
     
    <div>
        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
    </div>
</view>

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

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

Чтож. Буду краток! Когда?

WH>Если список просто переупорядочили (например отсортировали) то этот код просто передвинет куски ДОМ(если дом конечно такое позволяет я не в курсе)

Позволяет.

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

Z>Чтож. Буду краток! Когда?

Я это делать даже не начинал.
И если я начну делать это то ПЕГ будет делать некому.
Так что если есть желающие то готов оказать моральную и идеологическую поддержку.

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

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

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

ВВ>>Нет, я говорю с позиции практика. И на практике постоянно возникает необходимость спуститься на уровень ХТМЛ-я. Поэтому все абстракции, которые строятся над ним, попросту вредны. Я не знаю, как еще это объяснить. Это веб, это UI. В любой момент может возникнуть требование типа "все хорошо, ну тут надо фон поменять на серо-буро-малиновый, а здесь черточку дорисовать". И чего мне делать с этим Menu.builder?

VD>Дык Menu.builder это не более чем фунция. Подставь свою и вызови из нее все что нужно с нужными параметрами.

Подставить свою? И переписать весь код генерации меню что ли? А я же только самую малость подправить хочу.

ВВ>>Причем тут рекурсивность?
VD>Ну, право странно слышать это от человека который так ревностно отстаивал принципы ФП и хвалил ХСЛТ.

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

ВВ>>Контрол — это просто метод void Render(HtmlTextWriter). Все. Что там внутри — одному черту известно. Хочешь будет рекурсия, хочешь не рекурсия.
VD>Не контрол — это класс с кучей хрени вокруг. События рендереры, вьюстэйт и т.п.
VD>А метод есть метод. Создать метод — это пара нажатий на кнопку. А контрол создают только для отдельных случаев и очень редко.

"Хрень" — это то, что вешается уже сверху. Кстати, совершенно необязательная хрень. Для реализации контрола достаточно определить лишь Рендер. И он-то как раз и является костяком контрола. Чем это кардинально отличается от "просто функции" я не вижу.

ВВ>>Если же ты имеешь в виду, что веб-контрол обязан возвращать ХТМЛ, а не может вернуть, скажем, набор шаблонов, то да, это разница есть.
VD>Ага. И это очень большая разница.

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

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

Не, точным словом было "преувеличиваешь".

ВВ>>Все равно ты сделал веб-контрол, пусть и более навороченный.
VD>Он тебе мерещится. Поверь. Забудь про молоток и все перестанет казаться гвоздями.

Ну пока ты демонстрируешь молоток, что-то иное увидеть очень сложно. Единственное отличие от веб-контролов — "шаблоны порождающие шаблоны". Все. Даже если предположить, что это мировая фича, то тут все равно есть одна тонкость. Проблемы в том, что веб-контролы в веб формах возвращюсь ХТМЛ и не могут возвращать разметку АСП.НЕТ в общем-то не было. Зато были другие проблемы. Возникает вопрос — а что ты, собственно, лечишь-то?

ВВ>>МС уже ходила по этому пути, посмотри к чему они пришли после веб-формов — это уже *совсем* не веб-контролы.
VD>МС часто ходят черт знает куда. Не будем про них. Я тебе уже свое мнение высказал. Повторяться не хочу.

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

ВВ>>А ты, сдается мне, попросту не понимаешь, в чем *реальная* проблема у веб-форм.
VD>Я просто понимаю, что ты сейчас борешься со своим воображением.

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

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

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

Не похоже на другой подход. Правда не похоже.

ВВ>>Я предлагаю подумать. А мега-идей у меня с прошлого раза так и не появилось. Если появятся — обязательно расскажу.
VD>Ну, давай думать. Из разумных (возможно!) идей я вижу только предложение вольфхаунда использовать MVVM (аля Нокаут) и некий набор макросов для автоматизации и статической типизации этого дела.

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

ВВ>>Дело в том, что ХМТЛ, размазанный по коду на Немерле, абсолютно ничем не лучше. Ты вообще веб-страницу когда-нибудь делал сам-то?
VD>Писал. Даже на АСП без нет умудрился поработать.
ВВ>>Как, ты думаешь, люди это будут писать? Прям вот так вот, с чистого листа, взял и набросал таблички, стили — раз-раз и готово? Все равно сначала все будет писать в отдельном файлике, проверяться в браузере после каждого изменения (и не в одном, а во всех целевых), а потом уже переноситься в код. И вот когда держишь в голове такой юзкейс крутотень от ХМЛ-литералов как-то исчезает.
VD>Что все плохо я услышал. Что хорошо — нет.

А я тебе говорю — я не знаю, что хорошо. Подходов в общем много. Я вижу, что веб-приложения постепенно все больше и больше переплывают на клиента, а там уже клиентский темплейт энжин нужен и всякие Лифты тут не сильно помогут. Я вижу то, что на создание собственно UI в вебе уходит 60-90% времени от всей разработки. Потому что там единых стандартов нет — нарисовали дизайнеры хрень в фотожопе и надо воспроизвести один-в-один. Считай каждый проект делаешь UI, который раньше не делал, ибо фантазия у этих товарищей ого-го. И надо чтобы черточка к черточке сходилась. Тут в любом случае начинается все с того, что сидишь в блокноте и "рисуешь". От того, что у меня потом будет какая-то там статическая типизация этого ХТМЛ-я... вообще говоря, не очень ясно, что это мне даст-то. Больше гемороя блин, придется этот ХТМЛ еще по коду как-то размазывать.

Все это на бумаге хорошо выглядит и с тестовыми примерами, а на практике не очень-то и хорошо. Единственное, где мне ХТМЛ-литералы бы не помешали — это в ДжаваСкрипте. Ибо "из коробки" там только одна альтернатива — хреначить все через ДОМ. По сравнению с этим литерал — это конечно круто. Ну так может и делать компилятор в ДжаваСкрипт. Может и не нужен вообще традиционный серверный фреймворк? Можно написать сколь угодно сложное приложение, в котором UI формируется *только* на клиенте, а сервер лишь выдает данные — JSON там или XML. Может и двигать в таком направлении.

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

Z>>Чтож. Буду краток! Когда?

WH>Я это делать даже не начинал.
WH>И если я начну делать это то ПЕГ будет делать некому.
WH>Так что если есть желающие то готов оказать моральную и идеологическую поддержку.

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

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

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

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

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

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

Z>С одной стороны nemerle нужен сайт сейчас, с другой с таким view engine его можно будет на выставках показывать. Я склоняюсь к тому, что писать надо сейчас на том, что есть.
С таким view engine немерле и без сайта с руками и ногами отрывать будут.
Это какраз то самое KillerApplication про которое твердят большевики.

Для того чтобы довести это до версии без наворотов типа comet и клиентской многозадачности как в Ur/Web много времени не надо. Нужно только иметь их в виду.
На парсер благодаря ПЕГу уйдет несколько часов.
И несколько дней на то чтобы создать трансляторы в жабаскрипт и серверный код.
С серверным кодом вообще все просто. Там будет практически тупая трансляция методом что вижу то пою. Тут немерле рулит.
С жабаскриптом посложнее там реактивность нужно приделать но ПМ и рекурсия сильно облегяат задачу.

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

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

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

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

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

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

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

Эххх, если бы кто-то еще повторил и webmachine

Но это так — просто в общую копилку идей

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

WH>Для того чтобы довести это до версии без наворотов типа comet и клиентской многозадачности как в Ur/Web много времени не надо. Нужно только иметь их в виду.
WH>На парсер благодаря ПЕГу уйдет несколько часов.
WH>И несколько дней на то чтобы создать трансляторы в жабаскрипт и серверный код.
WH>С серверным кодом вообще все просто. Там будет практически тупая трансляция методом что вижу то пою. Тут немерле рулит.
WH>С жабаскриптом посложнее там реактивность нужно приделать но ПМ и рекурсия сильно облегяат задачу.

Боюсь мне понадобится на порядок больше времени, просто потому, что опыта написания трансляторов у меня нет.
Кроме самой трансляции нужна еще куча инфраструктурных моментов. Скорее всего он не ляжет как yet another view engine for asp.net mvc. Но, в принципе, его можно использовать параллельно.

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

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

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

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

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

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

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

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

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

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

M>Эххх, если бы кто-то еще повторил и webmachine

Но это так — просто в общую копилку идей

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

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

M>Эххх, если бы кто-то еще повторил и webmachine

Но это так — просто в общую копилку идей

Webmachine is an application layer that adds HTTP semantic awareness on top of the excellent bit-pushing and HTTP syntax-management provided by mochiweb, and provides a simple and clean way to connect that to your application's behavior.

Так прям как знал. Вольхаунду с Владом выделенное — точно понравится (см. там вверх и вниз по ветке)

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

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

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

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

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

M>>Эххх, если бы кто-то еще повторил и webmachine

Но это так — просто в общую копилку идей

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

Во-первых, они полностью реализуют логику HTTP, http://webmachine.basho.com/diagram.html

Что это дает?

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



// На все, что не GET webmachine вернет 405 Method Not Allowed
function allowed_methods() {
  return ['GET'];
}

// по умолчанию считается, что ресурс возвращает html
function to_html(ReqData, Context){
  UserID = ...
  return что-угодно-в хтмл
}

Хотим расширить это дело. Например, хотим показать 404 Not Found если пользователя нет. Просто добавляем resource_exists

// На все, что не GET webmachine вернет 405 Method Not Allowed
function allowed_methods() {
  return ['GET'];
}

// по умолчанию считается, что ресурс возвращает html
function to_html(ReqData, Context){
  UserID = ...
  return что-угодно-в хтмл
}

// если возвращаем false, то webmachien автоматом генерит 404 Not Found
function resource_exists(ReqData, Context){
  UserID = ...
  return UserID != 0
}

Эта же страница стала отвечать... Ну за создание пользователей. Нужен метод, отвечающий на POST:

// На все, что не GET webmachine вернет 405 Method Not Allowed
function allowed_methods() {
  return ['GET', 'POST'];
}

// по умолчанию считается, что ресурс возвращает html
function to_html(ReqData, Context){
  UserID = ...
  return что-угодно-в хтмл
}

// если возвращаем false, то webmachien автоматом генерит 404 Not Found
function resource_exists(ReqData, Context){
  UserID = ...
  return UserID != 0
}

// обрабатываем данные, пришедшие через POST
function process_post(ReqData, Context){
  db.query(...)
  return true; // 201 Created или мало ли что еще
}

Внезапно оказывается, что надо страницу прятать с глаз долой

// На все, что не GET webmachine вернет 405 Method Not Allowed
function allowed_methods() {
  return ['GET', 'POST'];
}

// по умолчанию считается, что ресурс возвращает html
function to_html(ReqData, Context){
  UserID = ...
  return что-угодно-в хтмл
}

// если возвращаем false, то webmachien автоматом генерит 404 Not Found
function resource_exists(ReqData, Context){
  UserID = ...
  return UserID != 0
}

// обрабатываем данные, пришедшие через POST
function process_post(ReqData, Context){
  db.query(...)
  return true; // 201 Created или мало ли что еще
}

function is_authorized(ReqData, Context){
  return true; // или false для 401 Unathorized
}

Ну и т.п. Ресурс доступен в виде другого content-type или разных content-type? Добавляем соответствующие функции. То есть вся REST-овая или REST-оподобная функциональность вынесена в отдельные функциональные блоки и легко расширяема в нужные стороны.

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

// стандартный момент практически в любом сайте

function someAction(){
   if (not user is authentified) return
   if(request is Post){ do_smth }
   else {do something_else }
}

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

В прошлый раз я все описал на интуитивном уровне.
Сейчас попробую формализовать.
Главное что нужно запомнить это ДСЛ, а не полноценный немерле.
Таким образом используется только часть конструкций и подмножество типов.
Типы и конструкции выбираются так чтобы не мешать реактивности.
Иначе каменный цветок не выдет.

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

Вьюхи имеют 2 синтаксических контекста.
1)Код
2)Тег
По умолчанию используется контекст код.
Когда встречается тег то мы переходим в режим тег. В этом режиме все что внутри тега считается тегом или текстом.
Тег как {} задает область видимости переменных.
Чтобы внутри тега перейти в режим код нужно перед началом кода написать "$".
Он съест одно выражение. Причем будет есть пока дают.
Каждое выражение может вернуть ноль или несколько значений одного типа.
Если эти значения теги то они оставляются как есть. Все другие типы конвертируются в строку и эскейпятся.

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

    def itemToAdd = "";

Присваивание. Всегда возвращает ноль значений типа тег.

    itemToAdd = "ыввыаыва";

Просто выражение. Всегда возвращает одно значение того типа который имеет это выражение.
Тип строка. Эскейпим.

    "ыввыаыва" + "123432542";

Тип int конвертируем в строку и эскейпим. Да я знаю что в инте эскейпить нечего. Но это вопрос оптимизации, а не семантики.

    123 + 234;

Тип тег. Возвращаем как есть.

    <p>Your values:</p>

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

match правила теже что и для if/else только веток может быть больше.

when и unless всегда возвращают список выражений.
Если условие обломилось то возвращают пустой список.

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

    foreach (item in selectedItems)
        <text>$item.Value</text>
    between
        <text>, </text>

Таким образом можно писать так:

view BetterListView(model : BetterListModel)
{
    def itemToAdd = "";

    <form submit -> model.addItem(itemToAdd); >
        Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
        <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
    </form>

    def selectedItems = [];

    <p>Your values:</p>
    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />

    <div>Selected items:
        $foreach (item in selectedItems)
            <text>$item.Value</text>
        between
            <text>, </text>
    </div>

    <div>
        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
    </div>
}

Также доступна такая форма записи:
foreach размножает тег по числу элементов в коллекции.
when/unless включают/выключают в зависимости от условия.

        <li foreach (person in model.people)>
        </li>
        <li when (asdqew)>
        </li>
        <li unless (hafdhas)>
        </li>

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

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

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

M>

M>// стандартный момент практически в любом сайте

M>function someAction(){
M>   if (not user is authentified) return
M>   if(request is Post){ do_smth }
M>   else {do something_else }
M>}
M>

Да нет, обычно делается что-то типа (тоже псевдокод):

route post /some_action, Some.somePostAction()
route get /some_action, Some.Action()

[RequireRole("User")]
function somePostAction()
{
   do_smth
}

[RequireRole("User")]
function someAction()
{
   do something_else
}

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

Идея контекстов отличная, мне очень нравится. Получаем лучшие стороны razor и spark.

WH>Каждое выражение может вернуть ноль или несколько значений одного типа.
WH>Если эти значения теги то они оставляются как есть. Все другие типы конвертируются в строку и эскейпятся.

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

WH>if/else. Обе ветки должны возвращать выражение одного типа.

тогда можно будет делать такое:

if (needParagarph)
  <p>Hello world</p>
else
  "Hello world"

Нужно еще дать простую возможность сделать такое:

<div data-${dataName}="someValue">

Нужна динамическая генерация списка атрибутов.

В принципе можно реализовать все это без реактивности, получится view-engine, а потом уже добавлять реактивность и все такое.

Остается еще проблема передачи параметров, очень хотелось бы "именованные туплы".

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

WH>С таким view engine немерле и без сайта с руками и ногами отрывать будут.
WH>Это какраз то самое KillerApplication про которое твердят большевики.

Такой движок, при условии качественной реализации, несомненно будет большим плюсом. Но боюсь я разочарую тебя, но киллером он не станет просто потому, что не все зациклены на вебе, а многие из тех кто зациклен привязаны (марально и социально) к разным недотехрологиям вроде АСП.НЕТ МВЦ с Разором, а то и к более тухлым.

WH>Для того чтобы довести это до версии без наворотов типа comet и клиентской многозадачности как в Ur/Web много времени не надо. Нужно только иметь их в виду.

Согласен. Думаю, что для реализации данной библиотеки нужно где-то человеко-месяц (с запасом). Так что если объеденить усилия, то можно и недели в две уложиться. Главное не пытаться сделать внешний ДСЛ. Он тут совершенно не нужен.

WH>На парсер благодаря ПЕГу уйдет несколько часов.

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

WH>И несколько дней на то чтобы создать трансляторы в жабаскрипт и серверный код.
WH>С серверным кодом вообще все просто. Там будет практически тупая трансляция методом что вижу то пою. Тут немерле рулит.
WH>С жабаскриптом посложнее там реактивность нужно приделать но ПМ и рекурсия сильно облегяат задачу.

А в чем проблема то? Можно использовать тот самый Нокаут и генерить код уже под него. Ну, а прочесть АСТ немерла и сгенерировать по нему жабаскрип это задача элементарная и много раз проделанная (аналогичный код есть в LINQ и Late).

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

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

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

Мы тебе поможем. Я постараюсь тратить на эту задачу некоторое количество времени. Заведи себе наконец скайп (все остальные давно общаются в нем). И в месте это это дело сварганим довольно быстро.

Z>Кроме самой трансляции нужна еще куча инфраструктурных моментов. Скорее всего он не ляжет как yet another view engine for asp.net mvc. Но, в принципе, его можно использовать параллельно.

А вот как раз эти вью энжыны и не нужны. Тогда все будет быстро и просто. Плясать надо от HttpHendler-а.

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

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

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

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

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

Тода вообще не ясно о чем ты тут ведешь речь. Внешний вид — это задача Кочеткова. Нам же нужна функциональность вики (в первую очередь версионность), многоязычность, микро-форумы и блоги. Тут шаблоны вообще никакого влияния не будут оказывать, так как 99% функционала будет динамическим контентом.

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

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

А дизайн и юзабилити оставь Кочеткову. Он на это дело подписался. С него и спрос. Лично я ему в этом вопросе полностью доверяю. Наша задача будет сделать именно программную логику. Серверную логику конечно это не отменит. Но явное выделение ViewModel сделает ее чётко структурированной, а значит легко изменяемой. А именно это и нужно для ускорения разработки и упрощения сопровождения.

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

WH>В прошлый раз я все описал на интуитивном уровне.
WH>Сейчас попробую формализовать.
WH>Главное что нужно запомнить это ДСЛ, а не полноценный немерле.

Ты мне скажи, ты перед тем как все это писать на Nemerle.Xml посмотрел?

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

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

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

WH>>if/else. Обе ветки должны возвращать выражение одного типа.
Z>тогда можно будет делать такое:
А что делать с таким кодом если мы все в тег превращаем?

def someInt = if (someThing)
  42
else
  24

Z>Нужно еще дать простую возможность сделать такое:
Z>

<div data-${dataName}="someValue">

Z>Нужна динамическая генерация списка атрибутов.
Вот это я не понял. Зачем?

Z>В принципе можно реализовать все это без реактивности, получится view-engine, а потом уже добавлять реактивность и все такое.
Можно и с этого начать.
Но нужно еще продумать описание интерфейса сервера.
Все подряд публиковать не смысла.
Более того нужно както отличать "data handler" от "view handler".
Первые отдают JSON вторые HTML.
Также нужен метод указания того какую вьюху на какую модель натягивать при вызове "view handler".

Z>Остается еще проблема передачи параметров, очень хотелось бы "именованные туплы".
Не понял ты о чем? Чего не хватает?

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

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

VD>Заведи себе наконец скайп (все остальные давно общаются в нем).

У меня давно есть скайп, я даже писал его тут. alex_zimin

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

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

И читабельность, очень важна читабельность когда ее надо поправить (т.е. всегда, имхо ни одна вьюха не дожила до релиза неправленной).

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

Z>>Может сделать так: каждое выражение может вернуть ноль или больше значений любых типов имеющих конвертор в тэг (строки будут конвертиться в псеводтэг text). Конверторы и будут эскейпить все что нужно.
WH>Можно и так. Но тут не все так просто.

Основная сложность происходит от списка тегов. Может их оборачивать в один?

WH>>>if/else. Обе ветки должны возвращать выражение одного типа.
Z>>тогда можно будет делать такое:
WH>А что делать с таким кодом если мы все в тег превращаем?
WH>

WH>def someInt = if (someThing)
WH>  42
WH>else
WH>  24
WH>

А все не надо. Если тег и не тег, конвертим в тег.

Z>>Нужно еще дать простую возможность сделать такое:
Z>>

<div data-${dataName}="someValue">

Z>>Нужна динамическая генерация списка атрибутов.
WH>Вот это я не понял. Зачем?

Допустим я хочу сделать такой тег

<div data-id="10" data-text="some text">

Z>>В принципе можно реализовать все это без реактивности, получится view-engine, а потом уже добавлять реактивность и все такое.
WH>Можно и с этого начать.
WH>Но нужно еще продумать описание интерфейса сервера.
WH>Все подряд публиковать не смысла.
WH>Более того нужно както отличать "data handler" от "view handler".
WH>Первые отдают JSON вторые HTML.
WH>Также нужен метод указания того какую вьюху на какую модель натягивать при вызове "view handler".

Мне нравится как это решается в рор: маршруты вида "/{somePath}[.{format}]" формат по умолчанию html.
Контроллер получается такой:

def action
  @data = get_some_data

  respond_with do |format|
     format.html render  # тут вьюха
     format.xml  @data.to_xml  # тут возвращаем xml
     format.json  @data.to_json  # тут джейсон
     format.js     "$('#data-list').append('<li>#{data.name}</li>')" # тут js, который что-то делает на странице
  end
end

/action и /action.html вернут отрендеренную вьюху
/action.xml — xml и т.д.

Z>>Остается еще проблема передачи параметров, очень хотелось бы "именованные туплы".
WH>Не понял ты о чем? Чего не хватает?

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

        public Show(id : int) : ActionResult
        {
            def doctor =  db.Doctors.Where(d => d.PersonID == id)
                .Select(d => new (
                    taxonomy = d.Taxonomy, 
                    name = new (
                        LastName = d.Person.LastName, 
                        MiddleName = d.Person.MiddleName, 
                        FirstName = d.Person.FirstName
                    )
                )).Single();

            def title = $"Doctor numer $id";
            View(viewmodel (doctor, title)); // Model : (doctor : (taxonomy : string, name : (LastName : string, MiddleName : string, FirstName : string)), title: string)
        }

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

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

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

Главная ошибка этого дизайна заключается в том, что вместо того чтобы пользоваться мощньешими средствами создания встроенных ДСЛ-ей ты предлагаешь создать внешний ДСЛ и обречь себя на все тяготы связанные с реализацией интелисенса. На сегодня у нас нет ничего для создания внешних ДСЛ-ей, а значит единственный способ сделать интелисенс для него — это реализовать еще один LanguageService. А это довольно объемная работа. Причем это будет голимый хардкод для одного частного случая. А мне такие решения категорически не нравятся. Уж если делать, что-то то универсально.

Причем все это на фиг не нужно поскольку не вооруженным взглядом видно, что все отлично реализуется встроенными ДСЛ-ями. Причем большая часть кода уже есть в Nemerle.Xml. Там есть ПЕГ-парсер ХМЛ-я со встроенными управляющими конструкциями. Ввести в них биндинг не составляет труда. Хотя я бы отказался от использования <-> так как знаки < и > конфликтуют с ХМЛ-ем внутрь которого они должны вставляться. В прочем, это технический вопрос который наверно можно решить, если что.

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

Конечно стоит, так как и Немерле и ХМЛ к нему чувствительны. Ну, а ХТМЛ-ю будет просто по фигу.

WH>Вьюхи имеют 2 синтаксических контекста.
WH>1)Код
WH>2)Тег

Теги Nemerle.Xml как раз и являются таким контекстом.

WH>По умолчанию используется контекст код.

Он уже есть в немерле. Любой код немерле и есть такой контекст. По сему нет никакого смысла делать немерле отдельным внешним ДСЛ-ем для немерле же. Это просто бессмысленно.

WH>Когда встречается тег то мы переходим в режим тег. В этом режиме все что внутри тега считается тегом или текстом.

Я бы сказал конструкциями описывающим теги, их генерацию или контент. Причем не текст, а именно контент. Именно так и поступает Nemerle.Xml. Все что попадает в него из вне и не является тегом эскейпится.

WH>Тег как {} задает область видимости переменных.

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

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

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

WH>Тип тег. Возвращаем как есть.
WH>

WH>    <p>Your values:</p>
WH>

Вот это заменяется на конструкцию:

xml <# <p>Your values:</p> #>

или даже на:

XElement("Your values:")

так как до трансляции в жадбаскрипт ХМЛ можно представлять как АСТ объектов XLinq. Это уже реализовано в Nemerle.Xml. В приципе от промежуточного представления можно и отказаться, но смысла в этом нет.

WH>foreach возвращает конкатенацию списков которые вернула каждая итерация.
WH>Особая форма foreach/between
WH>between вызавается после каждой итерации кроме последней.
WH>Может быть очень полезно для генерации списков с разделителем.
WH>

WH>    foreach (item in selectedItems)
WH>        <text>$item.Value</text>
WH>    between
WH>        <text>, </text>
WH>

Управляющих конструкций в Nemerle.Xml три: when, unless, foreach. Я это сделал намеряенно, чтобы не было желания создать жутко выглядящий код. Если ктому-то нужно более хитро манипулировать ХМЛ-ем, то нужно просто использовать возможнсоти немерла (локальные функции и фунции высшего порядка). Преобразовать все это в жабаскрипт не представляет проблемы.

WH>Таким образом можно писать так:
WH>

WH>view BetterListView(model : BetterListModel)
WH>{
WH>    def itemToAdd = "";

WH>    <form submit -> model.addItem(itemToAdd); >
WH>        Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
WH>        <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
WH>    </form>

WH>    def selectedItems = [];

WH>    <p>Your values:</p>
WH>    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />

WH>    <div>Selected items:
WH>        $foreach (item in selectedItems)
WH>            <text>$item.Value</text>
WH>        between
WH>            <text>, </text>
WH>    </div>

WH>    <div>
WH>        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
WH>        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
WH>    </div>
WH>}
WH>

Вот как будет выглядеть все тоже самое, но в виде внутреннего ДСЛ-я:

[View]
BetterListView(model : BetterListModel)
{
    def itemToAdd = "";
    def selectedItems = [];

    def selectedItemsText = selectedItems.
    
    xml <#
    <form submit -> model.addItem(itemToAdd); >
        Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
        <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
    </form> 
  
    <p>Your values:</p>
    <select multiple = multiple; height = 5; options <- model.items;  selectedOptions <-> selectedItems; />

    <div>Selected items:
        ..$(selectedItems; ", ")
    </div>

    <div>
        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
    </div> #>
}

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

WH>Также доступна такая форма записи:
WH>foreach размножает тег по числу элементов в коллекции.
WH>when/unless включают/выключают в зависимости от условия.
WH>

WH>        <li foreach (person in model.people)>
WH>        </li>
WH>        <li when (asdqew)>
WH>        </li>
WH>        <li unless (hafdhas)>
WH>        </li>
WH>

Вот их и нужно оставить. А совсем уж сложные конструкции исключить. Если надо пиши в коде выше и используй ХМЛ-фрагменты как значения.

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

То что описал я можно заставить взлететь менее чем за неделю.

Общий план реализации таков:
1. Берем ХМЛ-литералы (Nemerle.Xml) и допиливаем их чтобы они понимали синтаксис биндинга.
2. Делаем макро-атрибут View который бы вставлял в тело метода другой макрос. Назавем его ViewImpl.
3. ViewImpl тупо использует метод тайпера TransformWhenAllTypesWouldBeInfered() который позволяет дождаться окончания типизации фрагмента кода и в случае если типизация прошла успешно запускает функцию преобразования. Назовем ее ToJavaScript.
4. ToJavaScript получает на вход PExpr содержащий тело метода помеченного макро-атрибутом View и производит его анализ и трасформацию в JavaScript. При этом он может пользоваться квази-цитированием в паттерн-матчинге типами хранящимися в свойства PExpr.TypedObject. Это резко облегчит задачу трансформации и раннего выявления ошибок. Примерно так работает трансформация Linq-овских вызовов в деревья выражений.

Что мы теряем по равнению с оригинальным дизайном?
1. ХМЛ нужно обрамлять в xml <# #>.
2. Код представлений будет располагаться в обычных .n-файлах внутри классов.

Последнее на мой взгляд является преимуществом.

К подложенному Вольфхаундом дизайну я бы еще добавил одно мелкое, но очень мощьное расширение. Я бы позволил бы в генерируемом ХМЛ-е помещать ссылки на другие такие View, плюс задавать им параметры. Если выходной ХМЛ содержит ссылку на другой View, то она должна раскрыться подобно исходному вью.

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

[View]
BetterListView(model : BetterListModel)
{
    def itemToAdd = "";
    def selectedItems = [];

    def selectedItemsText = selectedItems.
    
    xml <#
    <form submit -> model.addItem(itemToAdd); >
        Add item: <input type = text; value <-> itemToAdd; valueUpdate = afterkeydown; />
        <button type = submit; enable <- !itemToAdd.IsEmpty; >Add</button>
    </form> 
  
    <p>Your values:</p>
    <!-- элемент ниже раскроется в то что было в исходном примере -->
    <controls.select options="model.items"  selectedOptions="selectedItems" /> 

    <div>Selected items:
        ..$(selectedItems; ", ")
    </div>

    <div>
        <button click -> model.removeItems(selectedItems); enable <- !selectedItems.IsEmpty; >Remove</button>
        <button click -> model.items.sort(); enable <- items.Length > 1; >Sort</button>
    </div> #>
}

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

Z>Мне нравится как это решается в рор: маршруты вида "/{somePath}[.{format}]" формат по умолчанию html.
Z>Контроллер получается такой:
Z>

Z>def action
Z>  @data = get_some_data

Z>  respond_with do |format|
Z>     format.html render  # тут вьюха
Z>     format.xml  @data.to_xml  # тут возвращаем xml
Z>     format.json  @data.to_json  # тут джейсон
Z>     format.js     "$('#data-list').append('<li>#{data.name}</li>')" # тут js, который что-то делает на странице
Z>  end
Z>end
Z>

Z>/action и /action.html вернут отрендеренную вьюху
Z>/action.xml — xml и т.д.

Да, еще, можно сделать и так:

def action
  @data = get_some_data
end

Тогда вьюха для рендера будет искаться в файле action.{format}.erb , соответственно логика рендера любого формата перекочует во view.

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

Z>У меня давно есть скайп, я даже писал его тут. alex_zimin

Я тебе отправил запрос.

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

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

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

Z>И читабельность, очень важна читабельность когда ее надо поправить (т.е. всегда, имхо ни одна вьюха не дожила до релиза неправленной).

По сравнению с тем что предложил вольфхаунд читабельность почти не пострадает.

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

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

Зачем какой-то "псеводтэг text" если есть понятие текст в ХМЛ? В Nemerle.Xml любые объекты автоматом превращаются в текст, если они исходно не являются элементами.

Z>Нужно еще дать простую возможность сделать такое:

Z>

<div data-${dataName}="someValue">

Такое конечно лучше не давать делать. А вот такое:

<div ${tagName}="someValue">

можно. Более того Nemerle.Xml это поддерживает (внимательно смотрим примеры кода в конце).

Z>Нужна динамическая генерация списка атрибутов.

Это тоже поддерживается. Смотри ссылку выше.

Z>В принципе можно реализовать все это без реактивности, получится view-engine, а потом уже добавлять реактивность и все такое.

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

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

Передачи куда?

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

Z>Допустим я хочу сделать такой тег
Z>

<div data-id="10" data-text="some text">

На это будет выглядеть так:

def attr = XAttribute("data-id", 10);
...
xml <#
<div $attr data-text="some text"> #>

Z>Мне нравится как это решается в рор: маршруты вида "/{somePath}[.{format}]" формат по умолчанию html.
Z>Контроллер получается такой:
Z>

Z>def action
Z>  @data = get_some_data

Z>  respond_with do |format|
Z>     format.html render  # тут вьюха
Z>     format.xml  @data.to_xml  # тут возвращаем xml
Z>     format.json  @data.to_json  # тут джейсон
Z>     format.js     "$('#data-list').append('<li>#{data.name}</li>')" # тут js, который что-то делает на странице
Z>  end
Z>end
Z>

Z>/action и /action.html вернут отрендеренную вьюху
Z>/action.xml — xml и т.д.

Это нужно вообще для любого ViewModel в автомате делать. В ХМЛ и джейсон. Если одно надо только что-то одно, то атрибут вешаем и все. Извини, что не могу привести код, так как его вообще не будет

.

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

Это у нас же MVVM-модель. На фиг в ней вообще передавать что-то окромя ViewModel во View?

Z>

Z>        public Show(id : int) : ActionResult
Z>        {
Z>            def doctor =  db.Doctors.Where(d => d.PersonID == id)
Z>                .Select(d => new (
Z>                    taxonomy = d.Taxonomy, 
Z>                    name = new (
Z>                        LastName = d.Person.LastName, 
Z>                        MiddleName = d.Person.MiddleName, 
Z>                        FirstName = d.Person.FirstName
Z>                    )
Z>                )).Single();

Z>            def title = $"Doctor numer $id";
Z>            View(viewmodel (doctor, title)); // Model : (doctor : (taxonomy : string, name : (LastName : string, MiddleName : string, FirstName : string)), title: string)
Z>        }
Z>

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

Дык ViewModel все равно декларировать. Предусмотреть в ней синтаксис позволяющий составные объекты и их списки хранить и все.
Можно описывать это дело как некий типизированный джейсон. Например, так:

[ViewModel]
class PersonViewModel
{
  Taxonomy : double;
  Name : { LastName : string; MiddleName : string; FirstName : string; }
  Children : Seq[LastName : string, MiddleName : string, FirstName : string]
}

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

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

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

VD>>Заведи себе наконец скайп (все остальные давно общаются в нем).

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

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

VD>Можно описывать это дело как некий типизированный джейсон. Например, так:
VD>

VD>[ViewModel]
VD>class PersonViewModel
VD>{
VD>  Taxonomy : double;
VD>  Name : { LastName : string; MiddleName : string; FirstName : string; }
VD>  Children : Seq[LastName : string, MiddleName : string, FirstName : string]
VD>}
VD>

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

Сори. Так как показал не прокатит. Но вот так можно сделать:

[ViewModel]
class PersonViewModel
{
  Taxonomy : double;
  Name     : Record[LastName : string, MiddleName : string, FirstName : string;];
  Children : Seq[LastName : string, MiddleName : string, FirstName : string];
}

Этот код можно раскрыть в:

class PersonViewModel : IViewModel
{
  public Taxonomy : Observable[double];
  public Name     : Observable[PersonViewModel_Name];
  public Children : Observable[PersonViewModel];

  public ToJson() : string { ... }
  public ToXml()  : string { ... }
}

class PersonViewModel_Name : IViewModel
{
  public LastName   : Observable[string];
  public MiddleName : Observable[string];
  public FirstName  : Observable[string];

  public ToJson() : string { ... }
  public ToXml()  : string { ... }
}

class PersonViewModel : IViewModel
{
  public LastName   : Observable[string];
  public MiddleName : Observable[string];
  public FirstName  : Observable[string];

  public ToJson() : string { ... }
  public ToXml()  : string { ... }
}

Ну, а далее использовать в коде и преобразовывать в JSON и XML.

Во IViewModel объявлены ToJson, ToXml и другая хрень нужная для работы с ViewModel.

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

Z>Допустим я хочу сделать такой тег
Z>

<div data-id="10" data-text="some text">

А зачем?

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

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

Z>>Допустим я хочу сделать такой тег
Z>>

<div data-id="10" data-text="some text">

WH>А зачем?

Не все же можно сделать рекативным? Когда-то придется и вручную попрограммировать.

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

VD>Не все же можно сделать рекативным?
Почему?

VD>Когда-то придется и вручную попрограммировать.
Не вижу когда это может понадобится.

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

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

VD>>Не все же можно сделать рекативным?
WH>Почему?

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

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

Главное что это ни разу не проблема.

VD>>Когда-то придется и вручную попрограммировать.
WH>Не вижу когда это может понадобится.

Ты слишком максималистичен.

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

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

VD>Простой пример. Мы хотим сделать подсветку синтаксиса кода в некоторых div-ах. Чтобы сэкономить время сервера делать это мы собрались на жабоскрипе. Для того чтобы жабоскрипт нашел div-ы и подсветил их как надо нам надо дать ему идентификатор. Ну и пододбная фигня нам упростит задачу.
1)Если мы смогли добавить что-то div'ам то мы могли им и аттрибут class прописать, а дальше все css сделает.
2)Если хочется на клиенте то делаем так:

    variant FormatedText
    {
        | Bold { text : FormatedText }
        | String { str : string; }
        | Text { texts : list[FormatedText] }
    }

    view FormatedTextView(text : FormatedText)
    {
        match(text)
        {
            | Bold(text)  => <strong>$FormatedTextView(text)</strong>
            | String(str) => str
            | Text(texts) =>
                foreach (text in texts)
                    FormatedTextView(text)
        }
    }

FormatedText приходит с сервера в виде JSON'а.

VD>Главное что это ни разу не проблема.
В чистом жабаскрипте это понятно зачем.
Но зачем оно тут мне не ясно совершенно.

VD>Ты слишком максималистичен.
Я реалистичен. И я не вижу зачем это может быть нужно.

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

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

WH>1)Если мы смогли добавить что-то div'ам то мы могли им и аттрибут class прописать, а дальше все css сделает.

Чтобы атрибут прописать тоже надо этот артибут задать динамически.

WH>2)Если хочется на клиенте то делаем так:
WH>FormatedText приходит с сервера в виде JSON'а.

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

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

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

VD>Чтобы атрибут прописать тоже надо этот артибут задать динамически.
А вот это вот что такое?
data-id="10" data-text="some text"
Откуда взялось? Почему вместо этого нелдьзя написать
class="someClass"
Ы?

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

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

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

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

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

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

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

M>>

M>>// стандартный момент практически в любом сайте

M>>function someAction(){
M>>   if (not user is authentified) return
M>>   if(request is Post){ do_smth }
M>>   else {do something_else }
M>>}
M>>

Z>Да нет, обычно делается что-то типа (тоже псевдокод):

Z>

Z>route post /some_action, Some.somePostAction()
Z>route get /some_action, Some.Action()

Z>[RequireRole("User")]
Z>function somePostAction()
Z>{
Z>   do_smth
Z>}

Z>[RequireRole("User")]
Z>function someAction()
Z>{
Z>   do something_else
Z>}
Z>

Это если язык такое позволяет

Самое главное в webmachine, имхо, то, что HTTP flow четко определен, и есть возможность грамотно «вклиниться» практически в каждый пункт той диаграммы

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

WH>Идеология реактивный MVVM.

Давай плясать от печки. В MVC урл биндится к экшенам контроллера, как поступить в MVVM? Биндимся к вьюхам? Тогда надо как-то научиться передавать между ними управление.

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

Z>Убрать необходимость можно (хоть и сложно).
Почему сложно?
Я просто не понимаю зачем они нужны если у нас все реактивное.
У нас все данные то есть совсем все хранятся в ViewModel.
View это всеголишь трансформированная ViewModel. Не более того.
Согласно моей идеологии для того чтобы что-то изменить во View нужно менять ViewModel, а View изменится сам.

Z>Но куда девать кучу готового клиентского кода, которые многие хотят реюзать?
А тебе не кажется что это клиентский код будет не совместим с кучей сгенерированного жабаскрипта?
Сам подумай что случится если ДОМ начнут корежить две программы которые ничего друг о друге не знают.
Еще мне очень интересно что это за код такой? И не станет ли он раз в 10-20 меньше если его переделать согласно моей идеологии.

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

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

Z>>Убрать необходимость можно (хоть и сложно).
WH>Почему сложно?
WH>Я просто не понимаю зачем они нужны если у нас все реактивное.
WH>У нас все данные то есть совсем все хранятся в ViewModel.
WH>View это всеголишь трансформированная ViewModel. Не более того.
WH>Согласно моей идеологии для того чтобы что-то изменить во View нужно менять ViewModel, а View изменится сам.

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

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

Z>>Но куда девать кучу готового клиентского кода, которые многие хотят реюзать?
WH>А тебе не кажется что это клиентский код будет не совместим с кучей сгенерированного жабаскрипта?
WH>Сам подумай что случится если ДОМ начнут корежить две программы которые ничего друг о друге не знают.
WH>Еще мне очень интересно что это за код такой? И не станет ли он раз в 10-20 меньше если его переделать согласно моей идеологии.

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

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

VD>А зачем вообще настаивать на ограниченном функционале, если сделать расширенный раз плюнуть?
Это не расширеный функционал. Это фигня которая делается чтобы было.
При этом никакой функциональности она не несет.
Ни ты ни Ziaw так и не сказали зачем оно надо кроме легиси жабаскрипта который к гадалке не ходи будет конфликтовать с тем что генерирует этот язык.
Просто по тому что и тот и другой код будут завязаны на разные инварианты состояния ДОМ.
Допустим при старте страници некий жабаскрипт что-то сделал со всем ДОМ и тут проснулся реактивный код и сгенерил еще ветки ДОМа. Кто скажет тому жабаскрипту обработать новые ветки? Как после этого будет выглядеть страница?
Пойми то что вы предлагаете похоже на запуск в одном адресном пространстве двух программ которые ничего друг о друге не знают.
Что будет когда они начнут читать и менять данные друг друга не понимая что там за данные?
Это же Core War получится.

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

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

Z>Не кажется, если они будут корежить разные куски DOM.
Что значит разные?
Весь ДОМ является всеголишь отрожением ViewModel.
По этому реактивный код будут корежить весь ДОМ.

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

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

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

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

От:	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

	От:	WolfHound
	Дата:	14.02.11 19:27
	Оценка:	16 (1)

От:	Mamut	http://dmitriid.com
Дата:	15.02.11 14:39
Оценка:

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	15.02.11 15:09
Оценка:	+1