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

Здравствуйте, 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
	Дата:	15.02.11 19:30
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	15.02.11 19:38
Оценка:

От:	VladD2	www.nemerle.org
Дата:	15.02.11 19:45
Оценка:

От:	VladD2	www.nemerle.org
Дата:	15.02.11 19:58
Оценка:

От:	VladD2	www.nemerle.org
Дата:	15.02.11 20:02
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	16.02.11 07:03
Оценка: