Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 13:09
Оценка:
Создал проект http://code.google.com/p/nemerleonrails/
В связи с этим возник вопрос:

есть классы модели для bltoolkit:
[Model] // макрос, генерирующий свойства и атрибуты маппинга по схеме БД (пока просто из заглушки)
class Doctor
{
}


И класс DbManager
[DbManager] // это гипотетический макрос...
class Db: DbManager
{
    public Doctors : Table[Doctor] //... который должен генерить вот такие свойства для кажого класса модели
    {
        get { this.GetTable.[Doctor]();}
    }
}


Как мне перебрать все классы помеченные макросом Model?
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>

13.12.12 21:11: Перенесено из 'Nemerle'
Re: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 09.04.10 13:24
Оценка: 12 (1)
Здравствуйте, Ziaw, Вы писали:

Z>Как мне перебрать все классы помеченные макросом Model?


Сделать модуль который обрабатывает логику макроса Model:
[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Class)]
macro Model(tb : TypeBuilder) {
   ModelImpl.RegisterType(tb);
}

[MacroUsage(MacroPhase.WithTypedMembers, MacroTargets.Class)]
macro Model(tb : TypeBuilder) {
  // основная логика макроса
}

module ModelImpl {

    types : List[TypeBuilder] = List();

    public RegisterType(tb : TypeBuilder) : void {
        types.Add(tb);
    }

}



На стадии BeforeInheritance запоминаем все типы, помеченные этим макросом, и на следующих стадиях в коллекции types уже будут TypeBuilder-ы.
/* иЗвиНите зА неРовнЫй поЧерК */
Re: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 13:26
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Создал проект http://code.google.com/p/nemerleonrails/


Вопрос не в тему. Ты там пишешь, что райнтайм расширение классов в дотнете не очень доступно. А что мешает? Есть же SRE, IDynamicObject.
Re[2]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 13:45
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вопрос не в тему. Ты там пишешь, что райнтайм расширение классов в дотнете не очень доступно. А что мешает? Есть же SRE, IDynamicObject.


Что такое SRE? Не очень — значит я не могу взять и просто добавить методы к имеющемуся классу не изменяя сам класс как в руби. Опять же, тулкит не замапит IDynamicObject, а если заставить его замапить, производительность будет страдать не слабо. Хотя, вероятно, будет все равно быстрее рельс.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[2]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 13:52
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вопрос не в тему.


Я тоже не в тему задам. Почему нет ни критики ни новых идей в тему? Я куда-то совсем не туда иду, что даже комментировать не хочется? Или мне одному видится перспективным данное направление? Все обсуждение заключается в спорах с Владом что лучше модель по базе или база по модели и еще один человек упорно доказывает, что круче рельс только рельсы и без копирования рельсовского ORM проект обречен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[3]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 13:53
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>не могу взять и просто добавить методы к имеющемуся классу не изменяя сам класс


Не очень удачно выразился. Имелось ввиду, чтобы добавлять методы необходимо чтобы сам класс был приспособлен к этому.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[3]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 14:04
Оценка:
Здравствуйте, Ziaw, Вы писали:

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

ВВ>>Вопрос не в тему. Ты там пишешь, что райнтайм расширение классов в дотнете не очень доступно. А что мешает? Есть же SRE, IDynamicObject.
Z>Что такое SRE? Не очень — значит я не могу взять и просто добавить методы к имеющемуся классу не изменяя сам класс как в руби. Опять же, тулкит не замапит IDynamicObject, а если заставить его замапить, производительность будет страдать не слабо. Хотя, вероятно, будет все равно быстрее рельс.

SRE — System.Reflection.Emit. С помощью него можно сэмитировать модель prototype OOP через delegation. Т.е. создается новый объект, он обворачивает ссылку на старый, в него могут добавлять новые свойства. Чтение старых свойств == чтение свойств прототипа. Запись новых == создание нового слота.

Про тулкит не скажу.

По скорости если все написать на голом рефлекшине все равно будет быстрее, чем Руби. Руби весьма не быстр, даже по сравнению с другими скриптами. Однако популярности ROR это не мешает.
По факту если нужна динамика — можно сделать динамику не хуже. Дотнет весьма динамичный рантайм. Надо понять все случаи, когда рулит динамика, насколько их все можно строго-типизировать.
Re[3]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 14:11
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Идеи штука такая, в мгновение ока не появляются. То, что ты предлагаешь — это улучшенный MVC с тулкитом в качестве ORM. Тут даже непонятно что сказать Если строго со стороны смотреть на все это дело, то я вижу, что предлагается более легкий синтаксис, т.е. все тоже самое, но надо писать меньше букв. Мне кажется этого... мало что ли.

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

Я бы больше смотрел в стороне первого — т.е. простоты создания. Таких проектов очень много, в т.ч. и в бизнесе. Монструозные приложения же как правило или а) уже написаны или б) пишутся на своих монструозных фреймворках, заточенных под свои конкретные сценарии и задачи.
Re[4]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 14:20
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>SRE — System.Reflection.Emit. С помощью него можно сэмитировать модель prototype OOP через delegation. Т.е. создается новый объект, он обворачивает ссылку на старый, в него могут добавлять новые свойства. Чтение старых свойств == чтение свойств прототипа. Запись новых == создание нового слота.


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

ВВ>По скорости если все написать на голом рефлекшине все равно будет быстрее, чем Руби. Руби весьма не быстр, даже по сравнению с другими скриптами. Однако популярности ROR это не мешает.


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

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


В рельсах
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[5]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 14:26
Оценка:
Здравствуйте, Ziaw, Вы писали:

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

Если задача просто в том, чтобы воспроизвести РОР со статической типизацией, то сначала надо показать, что все фичи РОР в эту самую статическую типизацию укладываются.
Re[4]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 14:35
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


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


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

Кстати еще идея возникла, насчет jscript. Так как все экшены и их параметры нам известны — аякс можно превратить в вид:
user.get(userId, function(user) {...});
// или
$("#userPlace").load(user.show(userId));

Рельсам такое будет сильно тяжело в рантайме считать, а для компайлтайма это все семечки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[5]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 14:41
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

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

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

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

Потом тема макросов раскрыта, а "тема сисек", извините, нет. Немерле не только язык с МП, но в отличие от Шарпа да и от Руби это полноценный ФЯ. А ФП как раз очень хорошо ложится на веб, на пользовательские интерфейсы. Ведь тут же стоит классическая задача — трансформация данных.

Z>Кстати еще идея возникла, насчет jscript. Так как все экшены и их параметры нам известны — аякс можно превратить в вид:

Z>
Z>user.get(userId, function(user) {...});
Z>// или
Z>$("#userPlace").load(user.show(userId));
Z>

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

Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно.
Re[6]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 14:44
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


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


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

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


Для этого надо знать на ВСЕ фичи ror. Если учесть, что ror это в первую очередь куча плагинов к ror, то врядли найдется такой человек. Что мешает не копировать весь РОР, а имплементить в каком-то порядке те фичи которые сильно облегчат жизнь в MVC? Тупо копировать ror жизни может не хватить, чтобы их догнать учитывая огромное комьюнити пишущее плагины. И еще, при полной копии и хорошем комьюнити, как только будет выходить новый релиз рельсов — все судорожно начнут хотеть фичи из нового релиза и ругаться, если ты их задержишь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[7]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 14:52
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Нене, тезис был в том, что практически все, что рельсы генерят динамикой можно узнать до рантайма. Если это можно сделать, зачем это все делать во время работы приложения а в момент разработки только надеяться на то, что у класса User появится свойство name?


Вот это на мой взгляд плохой подход к дизайну — "практически все, что рельсы...". При этом фичи РОР мы на самом деле не знаем полностью. Исследования не проводилось, просто делаем предположения. На этом и строится весь фреймворк. А я вот постоянно сталкиваюсь с тем, что для веб-приложений наиболее удобной моделью разработки является этакий REP-loop, и очевидные минусы динамики дают и очевидные плюсы — возможность менять состояние среды динамически, в процессе выполнения.

Я не предлагаю это писать на C#, как ты там обмолвился, упаси бог. Мне непонятно, почему использование Немерле и макросов должно означать отказ от любой динамики вообще, положенный в качестве design принципа в основание фреймворка. Когда при этом еще неясно какие фичи вообще будут.

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

Z>Для этого надо знать на ВСЕ фичи ror. Если учесть, что ror это в первую очередь куча плагинов к ror, то врядли найдется такой человек. Что мешает не копировать весь РОР, а имплементить в каком-то порядке те фичи которые сильно облегчат жизнь в MVC? Тупо копировать ror жизни может не хватить, чтобы их догнать учитывая огромное комьюнити пишущее плагины. И еще, при полной копии и хорошем комьюнити, как только будет выходить новый релиз рельсов — все судорожно начнут хотеть фичи из нового релиза и ругаться, если ты их задержишь.

Если задача создать что-то популярное, то да, надо знать ВСЕ фичи ror. Узнать ВСЕ фичи ROR гораздо проще все-таки, чем написать ROR-killer.
А MVC + syntax sugar это, мне кажется, на killer app как-то не тянет.
Re[6]: Nemerle on rails
От: WolfHound  
Дата: 09.04.10 14:55
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать.

Это кстати не так сложно как кажется.
За основу можно взять макрос Late.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 14:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

ВВ>>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать.

WH>Это кстати не так сложно как кажется.
WH>За основу можно взять макрос Late.

Late же вроде как сахар для рефлекшина.
Сложно или несложно — не знаю. Но компиляторы C# -> JavaScript есть. Думаю, на Немерле это уж по крайней мере не сложнее. Последнее время мне начинает казаться, что идея возможна не столь уж и плоха.
Re[6]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 15:00
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


М... что значит словами? Моя идея описана словами на гуглкоде. Она в том, чтобы избавиться от недостатков MVC которыми не страдает ror. Недостатки расписаны по пунктам. То, что туманных перспектив от немерла просто рой он распирает мою бедную голову, я не могу описать словами.

ВВ>Потом тема макросов раскрыта, а "тема сисек", извините, нет. Немерле не только язык с МП, но в отличие от Шарпа да и от Руби это полноценный ФЯ. А ФП как раз очень хорошо ложится на веб, на пользовательские интерфейсы. Ведь тут же стоит классическая задача — трансформация данных.


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

ВВ>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[8]: Nemerle on rails
От: WolfHound  
Дата: 09.04.10 15:05
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Late же вроде как сахар для рефлекшина.

Ну да. А для этого но код переписывает... Осталось его неределать чтобы он переписывал не в рефлекшен, а в жабаскрипт.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 15:10
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вот это на мой взгляд плохой подход к дизайну — "практически все, что рельсы...". При этом фичи РОР мы на самом деле не знаем полностью. Исследования не проводилось, просто делаем предположения. На этом и строится весь фреймворк. А я вот постоянно сталкиваюсь с тем, что для веб-приложений наиболее удобной моделью разработки является этакий REP-loop, и очевидные минусы динамики дают и очевидные плюсы — возможность менять состояние среды динамически, в процессе выполнения.


Идея понятна, а стоит ли делать делать эрланг из немерла?

ВВ>Я не предлагаю это писать на C#, как ты там обмолвился, упаси бог. Мне непонятно, почему использование Немерле и макросов должно означать отказ от любой динамики вообще, положенный в качестве design принципа в основание фреймворка. Когда при этом еще неясно какие фичи вообще будут.


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

ВВ>Если задача создать что-то популярное, то да, надо знать ВСЕ фичи ror. Узнать ВСЕ фичи ROR гораздо проще все-таки, чем написать ROR-killer.

ВВ>А MVC + syntax sugar это, мне кажется, на killer app как-то не тянет.

Хм... а кто пишет рор киллер? Когда писали ASP.NET MVC планировали рор киллер? А между прочим рор это и есть syntax sugar к ORM и роутингу. Плюс миграции. Его любят именно за DRY, который обеспечивается динамическим сахаром и скриптами генерации.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[2]: Nemerle on rails
От: Ziaw Россия  
Дата: 09.04.10 15:23
Оценка:
Здравствуйте, hardcase, Вы писали:

H>На стадии BeforeInheritance запоминаем все типы, помеченные этим макросом, и на следующих стадиях в коллекции types уже будут TypeBuilder-ы.

Сенкс, я и сам так хотел сделать. Волновали только два вопроса, не получится ли так, что заргуженная сборка компилятора будет вызывать один и тот же макрос несколько раз. И можно ли добавлять свойства в последующих фазах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[9]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 15:43
Оценка: 2 (1)
Здравствуйте, Ziaw, Вы писали:

Ну смотри, задача написать некий фреймворк, за который люди полюбят Немерле. По крайней мере именно в таком контексте это первоначально обсуждалось. На мой взгляд это достаточно серьезная заявка, и да в нее может входить и "РОР киллер", и "MVC киллер", и какой-нибудь еще киллер — в зависимости от того, кто будет является первичной аудиторией, так сказать. Это, кстати, первый вопрос, над которым стоит серьезно подумать, прежде чем отвечать.

Далее, чтобы полюбить Немерле "за фреймворк" нужно, чтобы этот фреймворк мог хорошо раскрыть сильные стороны Немерле. Макросы — это круто, но они *в лучшем случае* позволят сделать со статической типизацией то, что в Руби и иже с ним делается благодаря динамической. Очень легко, имея многолетний бэкграунд со статически-типизированными языками, увидеть в одном этом очень мощное преимущества. Но ты попробуй объяснить рубисту, что его динамическая типизация это фуфло. Одному вот в предыдущей ветке вы так и не объяснили, что SQL может быть строго-типизированным. К тому же не все так просто с этой динамикой, особенно в вебе.

Это если даже не говорить о том, что в современных веб-два-ноль — или сейчас уже модно веб-три-ноль? — приложениях куча ДжаваСкрипта. ДжаваСкрипт при этом 1) динамически типизированный, 2) слабо типизированный (в отличие, кстати, от руби) и 3) с ядреным prototype OOP через делегацию с помощью которого можно ядерную бомбу взорвать. А кода на нем приходится много писать. А получить крутые спец-эффекты там можно этак в n-раз покруче, чем на Руби.
И получается, что в процентом соотношении у нас "статического" будет не настолько уж больше, чем в Руби. Особенно, если это "правильный" Аякс, и мы на клиента именно данные вытаскиваем.

Итак, возвращаясь к нашим баранам. Что еще остается, кроме макросов? Повторюсь — ФП. Причем это не просто фича, это скорее и есть нужное направление. На том же ДжаваСкрипте зачастую удобнее писать в ФП-стиле. Тот же XSLT, популярный в роли шаблонизатора, это по сути ФП язык. И сие не случайно. Так как потоковая стейт-лесс модель преобразования данных очень хорошо ложится на веб. И если бывалому императивщику в обычной ситуации какие-то вещи в ФП могут показаться неудобными и непривычными, то как раз в вебе все уже к этому привыкли.

А ФП накладывает свой отпечаток на дизайн, причем серьезный такой. Я, повторюсь, не знаком с тулкитом, но, я так понимаю, это ORM, формирует некую модель, может, даже жирную. Насколько нам будут удобны все эти неповоротливые классы в функциональном языке? Хотелось бы алгебраические типы данных. Ведь мы же по сути пишем компилятор данных из БД в HTML.
Сюда же ложится и валидация всех сортов и форм — ее бы хотелось писать в декларативном ключе. И так далее.

В общем мне кажется тут сначала стоит просто посидеть и подумать, а не загонять себя с первого шага в какие-то рамки. Тогда может и правда киллер получится.
Re[3]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 09.04.10 15:44
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


H>>На стадии BeforeInheritance запоминаем все типы, помеченные этим макросом, и на следующих стадиях в коллекции types уже будут TypeBuilder-ы.

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

Метаатрибут вызывается ровно один раз в месте своего использования. BeforeInheritance это первая стадия, на которой доступно выполнение макросов. В примере у нас два разных макросы с одним и тем же именем, только один из них выполняется на этапе построения AST, а другой — после типизации членов класса (но до типизации тел методов).
/* иЗвиНите зА неРовнЫй поЧерК */
Re[9]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 15:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

ВВ>>Late же вроде как сахар для рефлекшина.
WH>Ну да. А для этого но код переписывает... Осталось его неределать чтобы он переписывал не в рефлекшен, а в жабаскрипт.

А, в этом смысле. Ну думаю повозиться все-таки придется, тот же матч в ДжаваСкрипт раскручивать. Если конечно не ограничиться очень маленьким сабсетом языка.
Re[3]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 09.04.10 17:04
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Почему нет ни критики ни новых идей в тему?


Я работал с MVC 1.0. Больше всего бесило нехилая куча тупых Model-классов, ведь модель часто это не просто экземпляр бизнесс-объекта, это еще и пачка каких-нибудь настроечных данных (вроде параметров пагинатору), при том автоматизировать их объявления у меня не получилось даже в Немерле. Тут кое кто пытался в заголовке метода указывать структуру ViewModel, но там не без проблем.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 19:23
Оценка: 12 (1)
Здравствуйте, Ziaw, Вы писали:

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


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

Кроме того проблему можно решить более радикально — добавить события в Manager (ManagerClass) которые вызывались бы при запуске и окончание компиляции. Ну, и подписываться на них, чтобы можно было обнулять нужные переменные.

Z>И можно ли добавлять свойства в последующих фазах.


Можно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 19:29
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Я тоже не в тему задам. Почему нет ни критики ни новых идей в тему? Я куда-то совсем не туда иду, что даже комментировать не хочется?


Думаю, что это потому, что идея пришла не одному тебе в голову. Ее даже не Воронков родил. Мы ее еще года 3 назад обсуждали еще в рамках развития движка рсдн.ру. Но до дела так и не дошли.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 19:30
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


А я бы с удовольствием почитал бы твое видение на аналогичную задачу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 19:37
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Кстати еще идея возникла, насчет jscript. Так как все экшены и их параметры нам известны — аякс можно превратить в вид:

Z>
Z>user.get(userId, function(user) {...});
Z>// или
Z>$("#userPlace").load(user.show(userId));
Z>


Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.

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


А что считать нужно? В чем сложность? Поясни, для не посвященных...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 19:40
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно.


А ты не хочешь тоже присоединиться к этому проекту?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 09.04.10 19:48
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.


Это вроде в GWT сделано было. Там правда Java в JavaScript транслируется...
/* иЗвиНите зА неРовнЫй поЧерК */
Re[6]: Nemerle on rails
От: seregaa Ниоткуда http://blogtani.ru
Дата: 09.04.10 19:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.


Ты случаем не Script# имеешь ввиду (http://rsdn.ru/forum/dotnet/3755719.aspx
Автор: barn_czn
Дата: 30.03.10
)? Его недавно упоминали на соседнем форме (.net). Там ява скрипт генерится по c# коду. Пишут, что проект даже используется в MS Exchange 2010.

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

DDL на немерле (а-ля ror migrations), DML на немерле (linq), клиентский скрипт тоже на немерле — интересная библиотека прорисовывается )))
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[5]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 19:58
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>А я бы с удовольствием почитал бы твое видение на аналогичную задачу.


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

В свое время мне очень нравилась идея X-Forms, если утрировать, то там все очень просто — есть XML, XSD и XSLT. Данные, контракт и трансформация. Если не бросаться на ХМЛ как на красную тряпку, то фактически имеем отличное разделение данных и вью и контракт для данных в декларативной форме, который также может использоваться при формировании вью.
И если лично мне нужно написать веб-приложение, то я возьму не MVC, ни тем более веб-формс, а именно XSLT, несмотря на его явные недостатки, ибо там и DRY работает куда лучше через подключение шаблонов — никакие юзер-контролы тебе такой гранулярности не дадут, — и паттерн-матчинг есть да и вообще на нем удобно описывать трансформацию, это же специально заточенный под эти цели язык.

(Но да, он пухлый и не очень мощный, я знаю).

А при таком подходе ORM не нужен класс. Нужен, если хочешь, XPathNavigator2Sql Зачем мне какие-то объекты — по сути графы, — с ними что-то делать, — по сути писать императивный код по анализу, называемый "бизнес-логикой". Мне нужно делать трансформацию от одной модели другой. Любой из лаеров — как его не назови, бизнес слой, не бизнес, апликейшин — может рассматриваться как еще один шаг трансформации.

При этом что еще конкретно дает XSLT — это просто чудовщную гибкость в плане "модульности". Можно подменить любую часть логики, любой шаблон, не меняя кода. Т.е. сделать этаки rewrite приложения, просто положив еще один файлик в папку.

Ну и для валидации не надо описать как именно валидировать — надо описывать *контракт*, которому должны удовлетворять данные.

Короче, ни ООП, ни императивный подход мне нужны в вебе. От них очень мало толку, а оверхед очень сильный.


+ Еще один момент. Клиентские сценарии. ДжаваСкрипт, хотя и создавался как язык для скриптования браузера, не очень хорошо заточен под работу с ХТМЛ ДОМом. Что и является основанием для появления всяких JQuery. Если делать компилятор Nemerle2JS или свой специальный DSL, то все эти жабоскриптовые фреймворки можно будет выкинуть на.
Re[6]: Nemerle on rails
От: seregaa Ниоткуда http://blogtani.ru
Дата: 09.04.10 20:14
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>+ Еще один момент. Клиентские сценарии. ДжаваСкрипт, хотя и создавался как язык для скриптования браузера, не очень хорошо заточен под работу с ХТМЛ ДОМом. Что и является основанием для появления всяких JQuery. Если делать компилятор Nemerle2JS или свой специальный DSL, то все эти жабоскриптовые фреймворки можно будет выкинуть на.


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

Можно потратить N месяцев и повторить этот путь (без гарантии на успех), а можно сесть поверх jquery и сэкономить это время.
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[7]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 20:31
Оценка:
Здравствуйте, seregaa, Вы писали:

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

S>Можно потратить N месяцев и повторить этот путь (без гарантии на успех), а можно сесть поверх jquery и сэкономить это время.

Какой путь повторять? Речь о генерации джава-скрипт кода, о компиляторе Немерле в ДжаваСкрипт. При таком подходе я не очень понимаю, как и куда можно втиснуть jQuery.

jQuery позволяет коротко писать сложный код, точнее — писать его декларативно. В данном случае эта задача решается на совершенно другом уровне.
Re[7]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 20:32
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Ага, а еще можно компилятор Немерле в ДжаваСкрипт сделать. Или добавить поддержку JS в виде макроса, но при этом со всеми плюшками ИДЕ. Много чего можно.

VD>А ты не хочешь тоже присоединиться к этому проекту?

А можно я пока просто посмотрю?
Re[7]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 20:33
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Да, это перебор. Для его реализации нужно иметь годичный опыт макростроения. Не меньше. Так что лучше эту идею отложить пока. Если ее реализовать в будущем, то прикрутить к рабочему проекту будет не сложно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 20:40
Оценка: 6 (1)
Здравствуйте, Ziaw, Вы писали:

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


Вот видишь, а ты спрашивал "зачем тебе немерле?". Получать от работы удовольствие — это ли не счастье?

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


Кстати, метаданные БД лучше в два этапа читать. На первом сериализовать их в некий формат (например, ХМЛ), а потом уже разбирать. Это позволит обходиться без наличия под рукой СУБД и не предотвратит тормоза при компиляции вызванные запросами к СУБД.

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


+1
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 20:41
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Задачи нужно решать по мере их появления. Ни то легко начать бороться с ветрянными мельницами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 20:44
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я не предлагаю это писать на C#, как ты там обмолвился, упаси бог. Мне непонятно, почему использование Немерле и макросов должно означать отказ от любой динамики вообще, положенный в качестве design принципа в основание фреймворка. Когда при этом еще неясно какие фичи вообще будут.


Мужики, расслабьтесь. Статическая компиляция не отменяет динамики хотя бы потому, что ее тоже можно делать в рантайме. Живет же себе АСП.НЭТ весьма динамически хотя код на шарпе?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.04.10 20:51
Оценка:
Здравствуйте, seregaa, Вы писали:

VD>>Кстати, можно воспользоваться идеей из какого-то F#-фрэймворка и генерировать jscript-код на базе кода написанного на немреле. Это не сложно. Тогда в проекте можно будет все писать на одном языке.


S>Ты случаем не Script#


Нет.


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

S>DDL на немерле (а-ля ror migrations), DML на немерле (linq), клиентский скрипт тоже на немерле — интересная библиотека прорисовывается )))

+1

Только я бы хотел не "а-ля ror migrations", а что-то более автоматизированное и менее императивное. В прочем, и так сойдет на первый раз.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Nemerle on rails
От: seregaa Ниоткуда http://blogtani.ru
Дата: 09.04.10 20:58
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Какой путь повторять? Речь о генерации джава-скрипт кода, о компиляторе Немерле в ДжаваСкрипт.


Вот исходный код jQuery функции, устанавливающей/считывающей значение атрибута dom элемента. Как видишь, это очень нетривиальный код, учитывающий особенности разных браузеров. Правда функция универсальная, умеет работать и с xml документом, но код, предназначенный для работы с html занимает большую часть функции.
    attr: function( elem, name, value, pass ) {
        // don't set attributes on text and comment nodes
        if ( !elem || elem.nodeType === 3 || elem.nodeType === 8 ) {
            return undefined;
        }

        if ( pass && name in jQuery.attrFn ) {
            return jQuery(elem)[name](value);
        }

        var notxml = elem.nodeType !== 1 || !jQuery.isXMLDoc( elem ),
            // Whether we are setting (or getting)
            set = value !== undefined;

        // Try to normalize/fix the name
        name = notxml && jQuery.props[ name ] || name;

        // Only do all the following if this is a node (faster for style)
        if ( elem.nodeType === 1 ) {
            // These attributes require special treatment
            var special = rspecialurl.test( name );

            // Safari mis-reports the default selected property of an option
            // Accessing the parent's selectedIndex property fixes it
            if ( name === "selected" && !jQuery.support.optSelected ) {
                var parent = elem.parentNode;
                if ( parent ) {
                    parent.selectedIndex;
    
                    // Make sure that it also works with optgroups, see #5701
                    if ( parent.parentNode ) {
                        parent.parentNode.selectedIndex;
                    }
                }
            }

            // If applicable, access the attribute via the DOM 0 way
            if ( name in elem && notxml && !special ) {
                if ( set ) {
                    // We can't allow the type property to be changed (since it causes problems in IE)
                    if ( name === "type" && rtype.test( elem.nodeName ) && elem.parentNode ) {
                        jQuery.error( "type property can't be changed" );
                    }

                    elem[ name ] = value;
                }

                // browsers index elements by id/name on forms, give priority to attributes.
                if ( jQuery.nodeName( elem, "form" ) && elem.getAttributeNode(name) ) {
                    return elem.getAttributeNode( name ).nodeValue;
                }

                // elem.tabIndex doesn't always return the correct value when it hasn't been explicitly set
                // http://fluidproject.org/blog/2008/01/09/getting-setting-and-removing-tabindex-values-with-javascript/
                if ( name === "tabIndex" ) {
                    var attributeNode = elem.getAttributeNode( "tabIndex" );

                    return attributeNode && attributeNode.specified ?
                        attributeNode.value :
                        rfocusable.test( elem.nodeName ) || rclickable.test( elem.nodeName ) && elem.href ?
                            0 :
                            undefined;
                }

                return elem[ name ];
            }

            if ( !jQuery.support.style && notxml && name === "style" ) {
                if ( set ) {
                    elem.style.cssText = "" + value;
                }

                return elem.style.cssText;
            }

            if ( set ) {
                // convert the value to a string (all browsers do this but IE) see #1070
                elem.setAttribute( name, "" + value );
            }

            var attr = !jQuery.support.hrefNormalized && notxml && special ?
                    // Some attributes require a special call on IE
                    elem.getAttribute( name, 2 ) :
                    elem.getAttribute( name );

            // Non-existent attributes return null, we normalize to undefined
            return attr === null ? undefined : attr;
        }

        // elem is actually elem.style ... set the style
        // Using attr for specific style information is now deprecated. Use style instead.
        return jQuery.style( elem, name, value );
    }


И это только одна из функций. Ты предлагаешь повторить весь этот код на немерле и транслировать его каждый раз обратно в js?

ВВ>При таком подходе я не очень понимаю, как и куда можно втиснуть jQuery.

Я вижу это как обертку над jQuery, транслирующую немерле код в вызовы методов скриптовой библиотеки.
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[8]: Nemerle on rails
От: seregaa Ниоткуда http://blogtani.ru
Дата: 09.04.10 21:05
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


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

Думаю, что js, как динамичный и функциональный язык и сам по себе обладает средставами для написания лаконичного кода. jQuery просто навязывает использование этих возможностей.
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[9]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 21:09
Оценка:
Здравствуйте, seregaa, Вы писали:

S>Я хочу сказать, что jquery — это не только краткая запись, а еще и удобная навигация по dom (селекторы) и кроссбраузерный набор функций для манипуляции dom-ом.

S>Думаю, что js, как динамичный и функциональный язык и сам по себе обладает средставами для написания лаконичного кода. jQuery просто навязывает использование этих возможностей.

Как ты себе представляшь код на Немерле, который будет транслироваться в ДжаваСкрипт? Ты же понимаешь, что это будет код именно на Немерле, функциональный, с паттерн-матчингом и пр. Ты сейчас предлагаешь один высокоуровневый код транслировать в другой, вместо того, чтобы разворачивать его в примитивные jscript-конструкции.
Найти нужный элемент DOMа можно, как ты понимаешь, и без jQuery, только кода придется писать больше. Но в данном случае этот код не пишется, он генерируется. В компайл-тайме. И его генерировать ну просто тупо проще.
Re[9]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 21:37
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Я не предлагаю это писать на C#, как ты там обмолвился, упаси бог. Мне непонятно, почему использование Немерле и макросов должно означать отказ от любой динамики вообще, положенный в качестве design принципа в основание фреймворка. Когда при этом еще неясно какие фичи вообще будут.

VD>Мужики, расслабьтесь. Статическая компиляция не отменяет динамики хотя бы потому, что ее тоже можно делать в рантайме. Живет же себе АСП.НЭТ весьма динамически хотя код на шарпе?

ASPX страница может и вполне динамичны, но ASP.NET проект это же не только ASPX, а еще и какой-нибудь Linq2Sql. И там уже никакого динамизма. Добавил новую колонку в базе — иди ребильд проект. И так во многих случаях. В РОРе многие вещи делать "по живому", ну прямо REPL чистой воды. Добавил, тут же поменял скрипт, нажал F5, откатил, добавил еще что-то — при разработке, баг-фиксинге, просто поиске решения это удобно.
Re[10]: Nemerle on rails
От: seregaa Ниоткуда http://blogtani.ru
Дата: 09.04.10 21:37
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Как ты себе представляшь код на Немерле, который будет транслироваться в ДжаваСкрипт? Ты же понимаешь, что это будет код именно на Немерле, функциональный, с паттерн-матчингом и пр. Ты сейчас предлагаешь один высокоуровневый код транслировать в другой, вместо того, чтобы разворачивать его в примитивные jscript-конструкции.


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


Да, управляющие конструкции Немерле придется транслировать в примитивные js конструкции. Но для работы с DOM одних примитивных js конструкций мало, нужно еще ввести примитивы, предоставляющие api к dom-у. На какое api отображать эти примитивы? Мое мнение — на одну из распространенных js библиотек, например на jQuery, поскольку она предоставляет унифицированный и оптимизированный доступ к DOM-у разных платформ. Чистый DOMDocument по факту нестандартизован и ведет себя в разных браузерах поразному.



Вообще мы по моему немного о разном говорим: ты — о трансляторе абстрактного немерле в абстрактный javascript, а я — о практическом применении такого транслятора. Меня единственное что смущает — твои слова о том, что с появлением такого транслятора "все эти жабоскриптовые фреймворки можно будет выкинуть на".
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[11]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 21:48
Оценка:
Здравствуйте, seregaa, Вы писали:

S>Да, управляющие конструкции Немерле придется транслировать в примитивные js конструкции. Но для работы с DOM одних примитивных js конструкций мало, нужно еще ввести примитивы, предоставляющие api к dom-у. На какое api отображать эти примитивы? Мое мнение — на одну из распространенных js библиотек, например на jQuery, поскольку она предоставляет унифицированный и оптимизированный доступ к DOM-у разных платформ. Чистый DOMDocument по факту нестандартизован и ведет себя в разных браузерах поразному.


Как же, стандартизирован W3C. Отличия у разных браузеров есть, но они не такие уж глобальные.
Ты сейчас выдвигаешь идею, что jQuery и подобные библиотеки используют, чтобы писать кроссплатформенный код? Их используют, чтобы меньше кода писать.
А ПМ это не просто управляющая конструкция, это и есть способ работы с ДОМом, превращать его во что-то вроде CSS селекторов попросту слишком сложно, да и не видно смысла. Большая часть DOM API везде работает одинаково, в ряде случаев достаточно просто нескольких проверок. Ну и да, если хочешь, какую-то часть jQuery придется повторить, просто повторять ее проще, чем jQuery использовать. Ибо разные идеологии.

Никто же не утверждал, что это так просто — Немерле в джаваскрипт компилировать.
Re[12]: Nemerle on rails
От: seregaa Ниоткуда http://blogtani.ru
Дата: 09.04.10 22:54
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Как же, стандартизирован W3C. Отличия у разных браузеров есть, но они не такие уж глобальные.

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

ВВ>Ты сейчас выдвигаешь идею, что jQuery и подобные библиотеки используют, чтобы писать кроссплатформенный код? Их используют, чтобы меньше кода писать.

Думаю, что jquery выбирают по совокупности фич.

ВВ>А ПМ это не просто управляющая конструкция, это и есть способ работы с ДОМом, превращать его во что-то вроде CSS селекторов попросту слишком сложно, да и не видно смысла.


То есть как это без селекторов? Т.е. вместо того, чтобы написать запрос вида "#list:first-child > td" нужно будет написать мач, который превратится в рукопашный js проход по dom-у? Учитывая, что современные браузеры поддерживают методы типа querySelector( ), выполняющие такие селекторы нативно, получится большой проигрыш в производительности. А если еще принять во внимание тот факт, что разные браузеры поддерживают разное подмножество селекторов, получается что транслировать селекторы нужно не в компайл тайме, а в рантайме. jquery например умеет преобразовывать селекторы в поддерживаемый браузером формат, причем делает это оптимальным для каждого браузера способом.


Ну да ладно, сначала нужно транслятор голого js написать, а уж примитивы для DOM-а — это дело второе
На сегодня закругляюсь )
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[13]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 09.04.10 23:08
Оценка:
Здравствуйте, seregaa, Вы писали:

ВВ>>Как же, стандартизирован W3C. Отличия у разных браузеров есть, но они не такие уж глобальные.

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

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

S>То есть как это без селекторов? Т.е. вместо того, чтобы написать запрос вида "#list:first-child > td" нужно будет написать мач, который превратится в рукопашный js проход по dom-у? Учитывая, что современные браузеры поддерживают методы типа querySelector( ), выполняющие такие селекторы нативно, получится большой проигрыш в производительности.


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

Самый смысл того, чтобы писать все на Немерле — это возможность в любом случае использовать те же самый конструкции языка. Поменял, скажем, атрибут у функции, и она стала исполняться на клиенте. Введение дополнительного DSL-я в виде CSS selector-ов тут портит всю малину. И ценность Немерлевского кода сильно падает.
Получается та же проблема, от которой хотели уйти, — одни и те же вещи решаются разными способами в зависимости от того, как исполняется код — на сервере или на клиенте. А смысл всех этих Script# и прочего как раз добиться обратного.
Re[10]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 00:33
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>Ну смотри, задача написать некий фреймворк, за который люди полюбят Немерле. По крайней мере именно в таком контексте это первоначально обсуждалось. На мой взгляд это достаточно серьезная заявка, и да в нее может входить и "РОР киллер", и "MVC киллер", и какой-нибудь еще киллер — в зависимости от того, кто будет является первичной аудиторией, так сказать. Это, кстати, первый вопрос, над которым стоит серьезно подумать, прежде чем отвечать.


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

ВВ>Далее, чтобы полюбить Немерле "за фреймворк" нужно, чтобы этот фреймворк мог хорошо раскрыть сильные стороны Немерле. Макросы — это круто, но они *в лучшем случае* позволят сделать со статической типизацией то, что в Руби и иже с ним делается благодаря динамической. Очень легко, имея многолетний бэкграунд со статически-типизированными языками, увидеть в одном этом очень мощное преимущества. Но ты попробуй объяснить рубисту, что его динамическая типизация это фуфло. Одному вот в предыдущей ветке вы так и не объяснили, что SQL может быть строго-типизированным. К тому же не все так просто с этой динамикой, особенно в вебе.


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

ВВ>Это если даже не говорить о том, что в современных веб-два-ноль — или сейчас уже модно веб-три-ноль? — приложениях куча ДжаваСкрипта. ДжаваСкрипт при этом 1) динамически типизированный, 2) слабо типизированный (в отличие, кстати, от руби) и 3) с ядреным prototype OOP через делегацию с помощью которого можно ядерную бомбу взорвать. А кода на нем приходится много писать. А получить крутые спец-эффекты там можно этак в n-раз покруче, чем на Руби.


Тут да. Функционален, рабоатет асинхронно и функциональность используется изза этого еще больше.

ВВ>И получается, что в процентом соотношении у нас "статического" будет не настолько уж больше, чем в Руби. Особенно, если это "правильный" Аякс, и мы на клиента именно данные вытаскиваем.


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


ВВ>А ФП накладывает свой отпечаток на дизайн, причем серьезный такой. Я, повторюсь, не знаком с тулкитом, но, я так понимаю, это ORM, формирует некую модель, может, даже жирную. Насколько нам будут удобны все эти неповоротливые классы в функциональном языке? Хотелось бы алгебраические типы данных. Ведь мы же по сути пишем компилятор данных из БД в HTML.

ВВ>Сюда же ложится и валидация всех сортов и форм — ее бы хотелось писать в декларативном ключе. И так далее.

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

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


Кто-то запретил думать? Или ты думаешь, что будет уже столько кода, что его не захочется переписывать? Я вот не могу просто думать, мне проще прототипы нактидывать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[6]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 00:33
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Кстати, метаданные БД лучше в два этапа читать. На первом сериализовать их в некий формат (например, ХМЛ), а потом уже разбирать. Это позволит обходиться без наличия под рукой СУБД и не предотвратит тормоза при компиляции вызванные запросами к СУБД.


Точно! Это еще решает проблему не до конца отмигрированной БД. После каждой успешной миграции мы просто скидываем метаданные в кеш. И генерим по нему.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[14]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 00:48
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Да, в рукопашный обход дерева. Да, медленее. Ну и что?

ВВ>querySelector вообще тренд новый, в "самом распространенном браузере" только в последней версии появился. Я тут проблемы не вижу.

А зачем забирать у людей то, что им уже нравится и предлагать что-то новое и непонятное?

ВВ>Самый смысл того, чтобы писать все на Немерле — это возможность в любом случае использовать те же самый конструкции языка. Поменял, скажем, атрибут у функции, и она стала исполняться на клиенте. Введение дополнительного DSL-я в виде CSS selector-ов тут портит всю малину. И ценность Немерлевского кода сильно падает.


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

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


Это напоминает мне попытку создать ORM которая делает вид, что никакой базы нет, а есть одни объекты в памяти. Не уверен, что стоит абстрагироваться от подобных вещей. А смысл всех этих языков видится в том, чтобы не мучать программиста прелестями обхода и создания дом и особенностями браузеров. Что успешно делает jQuery.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[4]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 00:53
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Я работал с MVC 1.0. Больше всего бесило нехилая куча тупых Model-классов, ведь модель часто это не просто экземпляр бизнесс-объекта, это еще и пачка каких-нибудь настроечных данных (вроде параметров пагинатору), при том автоматизировать их объявления у меня не получилось даже в Немерле. Тут кое кто пытался в заголовке метода указывать структуру ViewModel, но там не без проблем.


Одна из основных фич нового фреймворка избавиться от этого.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[4]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 00:54
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Проблему можно решить введя макро-атрибут уровня сборки в котором сбрасывать этот список.

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

VD>Кроме того проблему можно решить более радикально — добавить события в Manager (ManagerClass) которые вызывались бы при запуске и окончание компиляции. Ну, и подписываться на них, чтобы можно было обнулять нужные переменные.


Во, это уже мысль лучше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re: Nemerle on rails
От: WolfHound  
Дата: 10.04.10 15:28
Оценка: 20 (1)
Здравствуйте, Ziaw, Вы писали:

Тем кто еще не видел очень советую посмотреть на этот проект: http://www.impredicative.com/ur/
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 16:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WH>Тем кто еще не видел очень советую посмотреть на этот проект: http://www.impredicative.com/ur/


Вобщем-то если запихать вывод вьюх прямо в контроллер почти так получится и у нас. Возьмем например: http://www.impredicative.com/ur/demo/view.html
[Record]
class A { A : int } // вот тут только засада, fieldsOf u [A = int] мы не умеем, хотя было бы здорово
public Index() : ActionResult
{
    def list = fun(title : string, x : IEnumerable[IA]) 
    {
        def    html = x.Select(x => render <# <li>${x.A}</li> #>); // тут похоже какая-то свертка, не хочу сейчас разбираться в языке, верну перечислением
        
        render <# 
          <h2>${title}</h2> 
            <ul>${String.Join(html.ToArray(), "\n")}</ul>
        #>;
    }
    using (def db = new Db())
    {
        def listT = list("T", db.T.Select(t => A(t.A)));
        def listV = list("V", db.V.Select(v => A(v.A)));
        
        render <#
            ${listT}
            ${listV}
            <br/>
             <form action="${Action.Ins}">Insert: ${Html.TextBox("A")} <input type="submit"/></form>
        #>;
    }
}

public Ins(a : string) : ActionResult
{
    using (def db = new Db())
    {
        db.T.Insert(() => new {A = a});
        RedirectTo(Action.Index());
    }
}


Хотя я бы преписал list чуть императивнее:
    def list = fun(title : string, x : IEnumerable[IA])
    {
        render <# 
            <h2>${title}</h2> 
            <ul>
                <li each="xx in x">${xx}</li>
            </ul>
        #>;
    }


Отсалось добавить синтаксического сахара для работы с БД и код будет практически идентичен.

Непонятен только бенефит слияния логики и отображения. Все то же самое можно делать со внешними вьюхами
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[3]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 16:54
Оценка:
Здравствуйте, Ziaw, Вы писали:

Добавлю, что в данном примере я использовал только фичи из моего роадмапа и дополнительный макрос render для рендера спрака.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[3]: Nemerle on rails
От: Ziaw Россия  
Дата: 10.04.10 17:25
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Хотя я бы преписал list чуть императивнее:

Z>
Z>    def list = fun(title : string, x : IEnumerable[IA])
Z>    {
Z>        render <# 
Z>            <h2>${title}</h2> 
Z>            <ul>
Z>                <li each="xx in x">${xx}</li>
Z>            </ul>
Z>        #>;
Z>    }
Z>


Кстати, невеяло интересную идею. Что если рендер внешней вьюхи генерировать именно кодом внутри экшена? Правда придется написать свой парсер, но Влад утверждает, что это просто. Будут доступны все локальные переменные и можно будет не мучаться со способом передачи их из контроллера. Правда тут мы сразу потеряем динамическую компиляцию вьюх это очень жирный минус. И еще много потенциальных граблей. Но в рельсах как раз что-то похожее сделано.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[3]: Nemerle on rails
От: WolfHound  
Дата: 10.04.10 19:39
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Z>Вобщем-то если запихать вывод вьюх прямо в контроллер почти так получится и у нас. Возьмем например: http://www.impredicative.com/ur/demo/view.html

Там все статически типизировано.
Не смотря на то что это кажется текстом по факту это нихрена не текст.
Ибо компилятор проверяет теги на вшивость.
    return <xml>
      <h2>{[title]}</h2>
      <ul>{xml}</ul>
    </xml>

Собственно твой render может делать тоже смое.
Но в твоем варианте как я понял у тебя все насквозь строковое.
        render <# 
          <h2>${title}</h2> //Тут у тебя уязвимость. Ибо ничто не говорит о том что title нужно эскейпить.
          <ul>${String.Join(html.ToArray(), "\n")}</ul>//Тут тоже все криво. String.Join и ToArray явно не к месту.
        #>;

Вот если переделать так:
        render <# 
          <h2>$title</h2> //title имеет тип string. Экейпим.
          <ul>..$html</ul>//html имеет тип list[HTML]. Все уже заэскейплено.
        #>;

То мест для всяких там инжекшенов уже не останется.
Также очень классная фишка это автоматическая подстановка параметров в урл. Причем опять таки с правильным маршалингом:
http://www.impredicative.com/ur/demo/counter.html
fun counter n = return <xml><body>
  Current counter: {[n]}<br/>
  <a link={counter (n + 1)}>Increment</a><br/>
  <a link={counter (n - 1)}>Decrement</a>
</body></xml>

fun main () = counter 0

Причем оно умеет маршалить в том числе и весьма сложные структуры.

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

Z>Хотя я бы преписал list чуть императивнее:

Вот только императивщины не надо.

Z>Отсалось добавить синтаксического сахара для работы с БД и код будет практически идентичен.

LINQ лучше чем их сахар.

Z>Непонятен только бенефит слияния логики и отображения. Все то же самое можно делать со внешними вьюхами

Не хочешь не сливай.
Генерируй некое дерево из алгебраических типов в контроллере, а потом рендери его при помощи данной техники.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Nemerle on rails
От: WolfHound  
Дата: 10.04.10 19:39
Оценка:
Здравствуйте, Ziaw, Вы писали:

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

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

Например комуникационные сервисы Яндекса грубо говоря имеют два уровня:
1)Морда.
2)Бекенд.

На бекендах живут серванты которые по корбе отдают XML содержащий исключительно данные и ничего не знающий о том как это будет выглядеть.
На модах живет XScript http://xscript.opensource.yandex.net/
Это такая хрень которая по корбе дергает бекенд. Причем может дернуть сразу несколько паралельно.
Далее ждет когда бекенды ответят. Причем там есть два таймаута. Первый сколько ждать перед тем чтобы сказать пользователю что ничего не ответели.
И второй сколько еще подождать чтобы ответ можно было положить в кешь.

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

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

Nы не забывай что компилятор немерла это не ncc.exe, а Nemerle.Compiller.dll...

Z>И еще много потенциальных граблей. Но в рельсах как раз что-то похожее сделано.

Нужно делать не рельсы, а хаскрипт.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 10.04.10 20:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Тем кто еще не видел очень советую посмотреть на этот проект: http://www.impredicative.com/ur/

Да, это уже поинтереснее, чем ASP "с сиськами" Все-таки работа именно с текстовым шаблоном страницы весьма раздражает в ASP.NET.
Re[4]: Nemerle on rails
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 10.04.10 21:02
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>
WH>        render <# 
WH>          <h2>$title</h2> //title имеет тип string. Экейпим.
WH>          <ul>..$html</ul>//html имеет тип list[HTML]. Все уже заэскейплено.
WH>        #>;
WH>


Добавлю ровно две копейки:

1) эскейпим по разному, в зависимости от того, куда попала наша строка (см., например, microsoft anti-xss library на codeplex)

WH>То мест для всяких там инжекшенов уже не останется.


2) Правильно говорить: станет значительно меньше
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[5]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 10.04.10 22:23
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>1) эскейпим по разному, в зависимости от того, куда попала наша строка (см., например, microsoft anti-xss library на codeplex)



А не имеет ли смыл идея сделать специальный тип для эскейпнутых строк? Т.е. эскейпинг строки становится просто операцией приведения типа String в EscapeString. Там где нужен эскейпинг методы будут принимать второй тип, а там где он не обязателен — стандартный string.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 02:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Z>>Вобщем-то если запихать вывод вьюх прямо в контроллер почти так получится и у нас. Возьмем например: http://www.impredicative.com/ur/demo/view.html

WH>Там все статически типизировано.

У меня тоже. Кроме параметров форм. Гарантировать корректность которых действительно можно только в рантайме.

WH>Не смотря на то что это кажется текстом по факту это нихрена не текст.

WH>Ибо компилятор проверяет теги на вшивость.
WH>Собственно твой render может делать тоже смое.

Может, но вижу от этого пока больше проблем чем плюсов.

WH>Но в твоем варианте как я понял у тебя все насквозь строковое.

WH>
WH>        render <# 
WH>          <h2>${title}</h2> //Тут у тебя уязвимость. Ибо ничто не говорит о том что title нужно эскейпить.
WH>          <ul>${String.Join(html.ToArray(), "\n")}</ul>//Тут тоже все криво. String.Join и ToArray явно не к месту. 
WH>        #>;
WH>


Ескейпится так — $!{title}, вручную. Идея ескейпить по типу интересна. Мусор из String.Join и ToArray для дострочного воспроизведения. Я же показал, что я бы сделал все читабельнее и без мусора.

WH>То мест для всяких там инжекшенов уже не останется.


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

WH>Также очень классная фишка это автоматическая подстановка параметров в урл. Причем опять таки с правильным маршалингом:

WH>http://www.impredicative.com/ur/demo/counter.html
WH>
WH>fun counter n = return <xml><body>
WH>  Current counter: {[n]}<br/>
WH>  <a link={counter (n + 1)}>Increment</a><br/>
WH>  <a link={counter (n - 1)}>Decrement</a>
WH></body></xml>

WH>fun main () = counter 0
WH>


WH>Причем оно умеет маршалить в том числе и весьма сложные структуры.

Asp.net mvc тоже умеет. Хотя, весма сложные, расплывчатый термин.
public Counter(int i) : ActionResult
{
  render <#
        Current counter: ${i}<br/>
    <a link="${Action.Counter(i + 1).Url}">Increment</a>        
        <!-- или так -->
        ${Action.Counter(i - 1).Link("Decrement")}
#>
}


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

WH>И немерлом можно провернуть туже фишку.

Z>>Хотя я бы преписал list чуть императивнее:

WH>Вот только императивщины не надо.

Это религия чтоли? Там явно более декларативно выглядит, чем в функциональном стиле.

WH>Не хочешь не сливай.

WH>Генерируй некое дерево из алгебраических типов в контроллере, а потом рендери его при помощи данной техники.

Я вроде показал, что у меня должно получиться практически все, что там предлагается. Поэтому основной фичей показалось смешение вида и логики.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[5]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 03:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

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

Ты не поверишь, все что мы не умеем это рендерить гарантированно корректный html. И эта задача решается точечной сваркой. Кеширование в MVC из коробки.

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

WH>На модах живет XScript http://xscript.opensource.yandex.net/
WH>Это такая хрень которая по корбе дергает бекенд. Причем может дернуть сразу несколько паралельно.
WH>Далее ждет когда бекенды ответят. Причем там есть два таймаута. Первый сколько ждать перед тем чтобы сказать пользователю что ничего не ответели.
WH>И второй сколько еще подождать чтобы ответ можно было положить в кешь.

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


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

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

WH>Nы не забывай что компилятор немерла это не ncc.exe, а Nemerle.Compiller.dll...

Не забываю, но MVC не умеет перекомпилить контроллеры на лету. Хотя можно и научить наверное. Я пока не хотел вообще переделывать MVC, кроме viewengine.

WH>Нужно делать не рельсы, а хаскрипт.


Если предлагешь что-то, так хоть расскажи о возможностях, у меня реально нет вермени просматривать все примеры в юаре и одновременно изучать хаскрипт. Я сейчас пробую на вкус различные либы миграций и это отнимает реально много времени.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[5]: Nemerle on rails
От: WolfHound  
Дата: 11.04.10 10:28
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>У меня тоже. Кроме параметров форм. Гарантировать корректность которых действительно можно только в рантайме.

Увтор ура смог контролировать все во время компиляции.
Так что не вижу проблем.

WH>>Не смотря на то что это кажется текстом по факту это нихрена не текст.

WH>>Ибо компилятор проверяет теги на вшивость.
WH>>Собственно твой render может делать тоже смое.
Z>Может, но вижу от этого пока больше проблем чем плюсов.
Какие проблемы?
Я ни одной не вижу.
За то плюсов полно.

Z>Ескейпится так — $!{title}, вручную. Идея ескейпить по типу интересна.

Забыл ! и привет...
Так дело не пойдет.
Все нужно делать автоматом.

Z>Мусор из String.Join и ToArray для дострочного воспроизведения. Я же показал, что я бы сделал все читабельнее и без мусора.

Вот только семантика твоего кода весьма мутная.

WH>>То мест для всяких там инжекшенов уже не останется.

Z>Ну в HTML придется разрешить писать неэскейпленое, поэтому останется.
Зачем?

WH>>Причем оно умеет маршалить в том числе и весьма сложные структуры.

Z>Asp.net mvc тоже умеет. Хотя, весма сложные, расплывчатый термин.
Алгебраические типы.

Z>
Z>public Counter(int i) : ActionResult
Z>{
Z>  render <#
Z>        Current counter: ${i}<br/>
Z>    <a link="${Action.Counter(i + 1).Url}">Increment</a>        
Z>        <!-- или так -->
Z>        ${Action.Counter(i - 1).Link("Decrement")}
Z>#>
Z>}
Z>

А зачем .Url? Зачем другой метод сделать тоже самое?

Z>Это религия чтоли? Там явно более декларативно выглядит, чем в функциональном стиле.

Вот эта конструкция весьма мутная.
    def list = fun(title : string, x : IEnumerable[IA])
    {
        render <# 
            <h2>${title}</h2> 
            <ul>
                <li each="xx in x">${xx}</li>
            </ul>
        #>;
    }

Это может означать:
1)Размножить тег li подставив в каждый экземпляр очередной элемент.
2)Загнать все элементы из коллекции во внутрь тега.
3)Что-то еще?

Если уж делать то тогда так:
    def list = fun(title : string, x : IEnumerable[IA])
    {
        render <# 
            <h2>$title</h2> 
            <ul>
                ..$(render xx in x <# <li>${xx}</li> #>)
            </ul>
        #>;
    }

Но это уже получается просто вариация на тему Map

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

Главные фичи:
1)Полная статическая типизация.
2)Клиентския и серверный код пишутся на одном языке.

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

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

Архитектуру хаскрипта я считаю годной хотябы по тому что Яндекс чуть менее чем полность рендерится этой технологией.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 11:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

Z>>У меня тоже. Кроме параметров форм. Гарантировать корректность которых действительно можно только в рантайме.

WH>Увтор ура смог контролировать все во время компиляции.
WH>Так что не вижу проблем.

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

WH>Какие проблемы?


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

WH>Так дело не пойдет.

WH>Все нужно делать автоматом.
Повторюсь, идея ескейпить по типу интересна.

WH>>>То мест для всяких там инжекшенов уже не останется.

Z>>Ну в HTML придется разрешить писать неэскейпленое, поэтому останется.
WH>Зачем?
Если какая-то технология будет мешать мне писать то, что я хочу в респонс эта технология пойдет лесом.

Z>>Asp.net mvc тоже умеет. Хотя, весма сложные, расплывчатый термин.

WH>Алгебраические типы.
Как они будут выглядеть в C#? Acp.Net MVC может массивы объектов.

Z>>[code#]

Z>> <a link="${Action.Counter(i + 1).Url}">Increment</a>
Z>> <!-- или так -->
Z>> ${Action.Counter(i — 1).Link("Decrement")}
Z>>[/code]
WH>А зачем .Url? Зачем другой метод сделать тоже самое?
Url для чего угодно, для аякса например. Link для пользователей MVC привыкших к Html.ActionLink().

WH>Вот эта конструкция весьма мутная.

WH>
WH>                <li each="xx in x">${xx}</li>
WH>

WH>Это может означать:
WH>1)Размножить тег li подставив в каждый экземпляр очередной элемент.
WH>2)Загнать все элементы из коллекции во внутрь тега.
WH>3)Что-то еще?

Это означает ровно то, что написано в спецификации спарка. Размножить. Очень приятная фича. У меня сложилось впечатление, что ты считаешь это моим наколенным изобретением и записал в неудачные сразу.

WH>Если уж делать то тогда так:

WH>
WH>                ..$(render xx in x <# <li>${xx}</li> #>)
WH>

WH>Но это уже получается просто вариация на тему Map

Это жесть какая-то же. Ну ты сам сравни читаемость. Тег может быть любой величины, представь какие макароны получатся.
Попробуй в этом стиле переписать код:
<table if="products.Any()">
  <tr each="p in products">
        <td>$!{p.Name}</td>
        <td>$!{p.Price}</td>
        <td>$!{p.Location}</td>
  </tr>
</table>  
<else>
  <p>No products found.
</else>

Этот код интуитивно понятен и в нем отлично просматривается DOM. Этот код даже браузер неплохо покажет.

WH>Также учти что без серверного кода сложные отображения ты делать озвереешь. В тот же хаскрипт в конце концов воткнули луа ибо без серверной логики верстальщики вешались.

WH>И еще раз: Никто не заставляет пихать логику работы с базой во вьюхи.
WH>Ее можно вынести в отдельный класс, сборку, процесс, на другую машину,...
Я что-то не помню где я отказался от серверного кода Ты про ASP.NET MVC что знаешь? На нем все это реализуется из коробки.

WH>Архитектуру хаскрипта я считаю годной хотябы по тому что Яндекс чуть менее чем полность рендерится этой технологией.

А википедия рендерится на php, давай не будем тащить технологию без веских причин. То, что какая-то отдельно взятая компания ей пользуется не аргумент вообще. Догфудинг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[7]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 11.04.10 11:26
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Повторюсь, идея ескейпить по типу интересна.


Хм, вообще практика показывает что эскейпить лучше все строки, а как раз отключение экранирования наверно лучше сделать специальным типом.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[8]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 11.04.10 11:48
Оценка:
Здравствуйте, hardcase, Вы писали:

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


Z>>Повторюсь, идея ескейпить по типу интересна.


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


Или добавлять считать $!{bla} отключением экранирования, все таки у восклицательного знака семантика отрицания.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[9]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 12:10
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Или добавлять считать $!{bla} отключением экранирования, все таки у восклицательного знака семантика отрицания.


Тут проблема, люди привыкли писать ${Html.ActionLink()}
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[9]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 12:12
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Или добавлять считать $!{bla} отключением экранирования, все таки у восклицательного знака семантика отрицания.


На самом деле сам MVC что-то делает в сторону типизации экранирования, сейчас некогда искать просто.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[7]: Nemerle on rails
От: WolfHound  
Дата: 11.04.10 12:44
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Автор неаверное не встречал форм, поля для которых строятся на клиенте.

http://www.impredicative.com/ur/demo/subforms.html
Еще раз: Посмотри все демки.

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

хъ
Z>Если какая-то технология будет мешать мне писать то, что я хочу в респонс эта технология пойдет лесом.
Зачем?
Я правда не понимаю.

Z>Как они будут выглядеть в C#? Acp.Net MVC может массивы объектов.

А зачем C#?
Алгебраические типы то побольше могут.

Z>Url для чего угодно, для аякса например. Link для пользователей MVC привыкших к Html.ActionLink().

Ты не понял. Это просто лишнее. В теге link не может быть ничего кроме линка.

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

Z>Попробуй в этом стиле переписать код:
if (products.Any())
{
    render <#
        <table>
            $(render p in products<# 
                <tr>
                    <td>$(p.Name)</td>
                    <td>$(p.Price)</td>
                    <td>$(p.Location)</td>
                </tr>
            #>)
        </table>
    #>
}
else
    render <# <p> No products found. </p> #>

Можно провести декомпозиицию:
def renderProducts(products)
{
    def renderProduct(p)
    {
        render <#
            <tr>
                <td>$(p.Name)</td>
                <td>$(p.Price)</td>
                <td>$(p.Location)</td>
            </tr>
        #>
    }

    render <#
        <table>
            $(products.Map(renderProduct))
        </table>
    #>
}
if (products.Any())
    renderProducts(products);
else
    render <# <p> No products found. </p> #>


Z>Этот код интуитивно понятен и в нем отлично просматривается DOM. Этот код даже браузер неплохо покажет.

Зачем мне браузер?
Этот код на сервере должен работать.

Z>Я что-то не помню где я отказался от серверного кода Ты про ASP.NET MVC что знаешь? На нем все это реализуется из коробки.

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

Z>А википедия рендерится на php, давай не будем тащить технологию без веских причин. То, что какая-то отдельно взятая компания ей пользуется не аргумент вообще. Догфудинг.

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

Единственный минус хаскрипта это XSLT. Мы можем от этого избавиться.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 13:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

Z>>Автор неаверное не встречал форм, поля для которых строятся на клиенте.

WH>http://www.impredicative.com/ur/demo/subforms.html
Этот пример строит их на сервере.

WH>Еще раз: Посмотри все демки.

Лень.

WH>Зачем?

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

Z>>Как они будут выглядеть в C#? Acp.Net MVC может массивы объектов.

WH>А зачем C#?
WH>Алгебраические типы то побольше могут.
Мне бы ответ на вопрос. Можно в немерле.

Z>>Url для чего угодно, для аякса например. Link для пользователей MVC привыкших к Html.ActionLink().

WH>Ты не понял. Это просто лишнее. В теге link не может быть ничего кроме линка.
Код который я пишу я могу объяснить, как он работает и что откуда берется. Если я уберу Link() я не пойму какой тип будет возвращать Action.Blbla.

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

Z>>Попробуй в этом стиле переписать код:
WH>
WH>            $(render p in products<# 
WH>


Ну жесткая жесть же. Рельсы любят за краткость и выразительность. Это гораздо хуже спарка.

Z>>Этот код интуитивно понятен и в нем отлично просматривается DOM. Этот код даже браузер неплохо покажет.

WH>Зачем мне браузер?
WH>Этот код на сервере должен работать.
Это не отменяет первых двух пунктов.

WH>Почтиал. И так и не понял смысла разделения на вьюхи и контроллеры при условии что у нас есть макрос render.

Контроллеры теструемы. Вьюхи компилируемы на лету.

WH>Единственный минус хаскрипта это XSLT. Мы можем от этого избавиться.


Вобщем итог дискуссии можно уже подводить. Макрос рендер нужен. После бэты я им займусь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[8]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 13:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Почтиал. И так и не понял смысла разделения на вьюхи и контроллеры при условии что у нас есть макрос render.

И еще. Вьюхи это еще и темы. Т.е. легко меняющийся вид сайта без переделки логики.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[9]: Nemerle on rails
От: WolfHound  
Дата: 11.04.10 13:35
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Этот пример строит их на сервере.

http://www.impredicative.com/ur/demo/listEdit.html

WH>>Еще раз: Посмотри все демки.

Z>Лень.
Глупо.

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

Можно для таких случаев сделать функцию Hack.CastToHTML.

Z>>>Как они будут выглядеть в C#? Acp.Net MVC может массивы объектов.

WH>>А зачем C#?
WH>>Алгебраические типы то побольше могут.
Z>Мне бы ответ на вопрос. Можно в немерле.
Ничего не понял.

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

Никакой. Это не вызов. Это замыкание.

Z>Ну жесткая жесть же. Рельсы любят за краткость и выразительность. Это гораздо хуже спарка.

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

Z>Контроллеры теструемы.

Контроллеры это не более чем точки входа.
Просто выносим от туда все что не касается интерфейса и спокойно тестируем.

Z>Вьюхи компилируемы на лету.

И что мешает на лету компилировать всю морду?

Если ASP.NET то при наличии макры render он становится не нужным чуть мнее чем полностью.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Nemerle on rails
От: WolfHound  
Дата: 11.04.10 13:44
Оценка:
Здравствуйте, Ziaw, Вы писали:

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

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

Бекенды о фронтендах вообще ничего не знают.
Фронтенды знают только интерфейс бекендов.

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

Короче все твои претензии по архитектуре мягко говоря мимо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 14:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Z>>Этот пример строит их на сервере.

WH>http://www.impredicative.com/ur/demo/listEdit.html
Я себе мозг сломал читая этот пример, нафиг юар, я не собираюсь его повторять.

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

WH>Никакой. Это не вызов. Это замыкание.
Это выглядит как замыкание. На самом деле оно рендерится в урл. В юаре также. Ты предалагаешь какой-то совершенно новый подход, который не оставит камня на камне от MVC. Это месяцы, а то и годы кропотливой работы, прежде чем это что-то можно будет использовать для создания сайтов. Мне такой путь не подходит, если есть желание пройди его сам. Я собираюсь для начала сделать более удобный MVC. Чтобы было от чего плясать, на чем работать и обкатывать новые идеи.

Z>>Ну жесткая жесть же. Рельсы любят за краткость и выразительность. Это гораздо хуже спарка.

WH>Если тебе так хочется сделать размножение то сделай.
WH>Но и этот способ должен быть.
А его никто не отнимает по идее.

Z>>Контроллеры теструемы.

WH>Контроллеры это не более чем точки входа.
WH>Просто выносим от туда все что не касается интерфейса и спокойно тестируем.
Куда выносим? Сначала вносим туда view, потом выносим оттуда всю логику? Ну будет у нас называться контроллер, а по сути быть view, что это даст?

Z>>Вьюхи компилируемы на лету.

WH>И что мешает на лету компилировать всю морду?
Весь сайт? Это не быстро, это заставит выкинуть мвц или переписать его большую часть.

WH>Если ASP.NET то при наличии макры render он становится не нужным чуть мнее чем полностью.

Макра рендер будет побочным эффектом своего view engine. ASP.NET это не только генерация страничек a la t4.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[10]: Nemerle on rails
От: Ziaw Россия  
Дата: 11.04.10 15:00
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

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

WH>Бекенды о фронтендах вообще ничего не знают.

WH>Фронтенды знают только интерфейс бекендов.
классика MVC

WH>Пишут их совершенно разные люди.

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

WH>Короче все твои претензии по архитектуре мягко говоря мимо.

Да я не увидел еще никакой архитектуры, кроме заявлений как это круто. Фронтэнды, бэкенды, это все общие шаблоны, в которые МВЦ тоже укладывается, ты объясни рядовому сайтостроителю зачем ему все это. Потом я посмотрю.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[11]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 11.04.10 20:33
Оценка:
Здравствуйте, Ziaw, Вы писали:

WH>>Бекенды о фронтендах вообще ничего не знают.

WH>>Фронтенды знают только интерфейс бекендов.
Z>классика MVC

Я не понимаю, зачем ты уперся рогом в этот ASP.NET MVC. MVC вообще не самый удачный паттерн, он весьма тяжеловесный, что прекрасно себя показывает в ASP.NET MVC. И все, что ты собираешься сделать — решать проблемы этого паттерна с помощью макросов Немерле. Может, не стоит лечить симптомы?
А ASPX это вообще что-то дремучее, как шаблонизатор он просто дико сосет у того же XSLT.

Ты пойми, никому не нужен "ASP 4.0 с макросами".

WH>>Пишут их совершенно разные люди.

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

А вот мне нужно. Как быть?

WH>>Короче все твои претензии по архитектуре мягко говоря мимо.

Z>Да я не увидел еще никакой архитектуры, кроме заявлений как это круто. Фронтэнды, бэкенды, это все общие шаблоны, в которые МВЦ тоже укладывается, ты объясни рядовому сайтостроителю зачем ему все это. Потом я посмотрю.

Ты даже не посмотрел все примеры для Ur/Web. А ведь очень интересная штука. Казалось бы, классно, есть готовые прототипы, созданные на ФЯ, с соответствующей идеологией — но нет, ASP это наше все.
Re[12]: Nemerle on rails
От: Ziaw Россия  
Дата: 12.04.10 00:58
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я не понимаю, зачем ты уперся рогом в этот ASP.NET MVC. MVC вообще не самый удачный паттерн, он весьма тяжеловесный, что прекрасно себя показывает в ASP.NET MVC. И все, что ты собираешься сделать — решать проблемы этого паттерна с помощью макросов Немерле. Может, не стоит лечить симптомы?


Расскажи про тяжеловесность рельсовикам. Там mvc. Давай посмотрим, от чего мы можем избавиться в этой связке — модель у тебя останется, как не крути, с базой работать придется. Итак база/модель остается. Логику ты не выкинешь, с базой придется работать осмысленно. Все что ты можешь, засунуть представление прямо в логику — макрос рендер. Я не против, мой прототип это позволит.

ВВ>А ASPX это вообще что-то дремучее, как шаблонизатор он просто дико сосет у того же XSLT.

ВВ>Ты пойми, никому не нужен "ASP 4.0 с макросами".

Мне нужен. Про aspx вообще речи не идет.

WH>>>Пишут их совершенно разные люди.

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

ВВ>А вот мне нужно. Как быть?


Сделай

ВВ>Ты даже не посмотрел все примеры для Ur/Web. А ведь очень интересная штука. Казалось бы, классно, есть готовые прототипы, созданные на ФЯ, с соответствующей идеологией — но нет, ASP это наше все.


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

И самое главное — никакого желания не появилось взять и сделать на нем сайтик по быстрому!

Кто из вас сделал? Не примеры посмотрел, а просто что-то сделал? Пусть тот же блог за 20 минут как в туториалах по рельсам? Сделайте плиз, выложите и расскажите как классно и быстро это у вас получилось. Только, боюсь, тошнить вас начнет от этого проекта задолго до окончания.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[13]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 12:27
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Расскажи про тяжеловесность рельсовикам. Там mvc. Давай посмотрим, от чего мы можем избавиться в этой связке — модель у тебя останется, как не крути, с базой работать придется. Итак база/модель остается. Логику ты не выкинешь, с базой придется работать осмысленно. Все что ты можешь, засунуть представление прямо в логику — макрос рендер. Я не против, мой прототип это позволит.


Отделение презентации и логики — это хорошо. Но есть и другие паттерны. Есть хотя бы просто другие подходы к тому же MVC, не обязательно такие как в Рельсах. Взять хотя бы AIDA/Web.

Z>Ребят, поймите, у меня возникла идея, понравилась, я ее решил реализовать. А вы мне говорите — тебе не то понравилось, давай тебе понравятся прототипы ФЯ.


То, что ты хочешь сделать... В общем для этого и Немерле-то не нужен. Достаточно C# с динамиком да билд провайдеров асп-нета, которые в данном случае будут не сильно хуже макросов. И все, блюдо готово.

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

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

Z>И самое главное — никакого желания не появилось взять и сделать на нем сайтик по быстрому!
Z>Кто из вас сделал? Не примеры посмотрел, а просто что-то сделал? Пусть тот же блог за 20 минут как в туториалах по рельсам? Сделайте плиз, выложите и расскажите как классно и быстро это у вас получилось. Только, боюсь, тошнить вас начнет от этого проекта задолго до окончания.

Писать на юр-веб никто не предлагает. Изучить, взять идеи — да. Конечно, это не РОР, за которым стоит бабло Эпла, и нет красивых туториалов с картинками в стиле "создай веб-приложение за 5 минут". Для Немерле их тоже нет. И у многих, кто заходит на nemerle.org точно такая же в общем-то реакция. Это не значит, что вещь плохая.
И от чего там начинает "тошнить"? Не от HTML литералов же? Если есть какие-то конкретные претензии их и надо обсуждать, т.к. это те области, которые можно сделать лучше.
Re[14]: Nemerle on rails
От: Ziaw Россия  
Дата: 12.04.10 13:25
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Отделение презентации и логики — это хорошо. Но есть и другие паттерны. Есть хотя бы просто другие подходы к тому же MVC, не обязательно такие как в Рельсах. Взять хотя бы AIDA/Web.


Гляну.

Z>>Ребят, поймите, у меня возникла идея, понравилась, я ее решил реализовать. А вы мне говорите — тебе не то понравилось, давай тебе понравятся прототипы ФЯ.


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


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

ВВ>Писать на юр-веб никто не предлагает. Изучить, взять идеи — да. Конечно, это не РОР, за которым стоит бабло Эпла, и нет красивых туториалов с картинками в стиле "создай веб-приложение за 5 минут". Для Немерле их тоже нет. И у многих, кто заходит на nemerle.org точно такая же в общем-то реакция. Это не значит, что вещь плохая.

ВВ>И от чего там начинает "тошнить"? Не от HTML литералов же? Если есть какие-то конкретные претензии их и надо обсуждать, т.к. это те области, которые можно сделать лучше.

Ты создай и покажи. Я не хочу равняться на язык на котором простой сайт сделать проблема. Псевдозамыкания я и так планировал сделать. Возможно в будущем посмотрю на него еще, когда для jscripta буду что-то писать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[15]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 13:59
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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


Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная. В РОР по определению никаких статических проверок, и людям это нравится. Вопрос, насколько необходимы именно статические, т.е. на этапе компайл-тайма, проверки в веб-приложении. Ведь здесь грань между компайл-таймом и рантаймом стирается. Возьмем тот же ASPX без код бехаинда. Ведь *семантически* он просто напросто убирает стадию компиляции, она по-прежнему есть, но как бы спрятана от пользователя.
В итоге те статические проверки, которые ты добавишь, могут мало чем отличаться от динамических. Важнее, чтобы они в принципе были. И в Руби они есть (а вот в JS, кстати, отсутствуют).
Re[16]: Nemerle on rails
От: Ziaw Россия  
Дата: 12.04.10 14:25
Оценка:
Здравствуйте, Воронков Василий, Вы писали:


ВВ>Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная.


Покажи как на C# 4.0 сделать такое:
        public Index() : ActionResult {
            using (def db = Db())
            {
                ViewData["Message"] = $"NRails env: '$(db.Env)'. We have $(db.Persons.Count()) persons."; 
                ViewData["Taxonomies"] = db.Doctors.Select(d => d.Taxonomy).ToList();
            }
            
            View()
        }
// где
  [DatabaseManager]
  class Db: DbManager {}
  [Model]
    public class Doctor    {}

Это уже работает у меня.

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


Если бы всех устраивал рор, asp.net mvc был бы никому не нужной безделицей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[11]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 14:25
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


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

Z>Рельсы любят именно за то, что они делают своей динамикой.


И вот это весьма важный момент.

Z>А рубистам можно дать быстродействие. Поверь, никого полностью не устраивает скорость рельс.


Я уже говорил — Руби сам по себе очень медленный. А Рельсы явно еще добавляют свой "слой тормозов". Причем Руби медленный не по сравнению с C# или Немерле, а по сравнению с Питоном, ДжаваСкриптом и пр.
Однако же РОР-ом пользуются, пусть никого "полностью не устраивает скорость рельс". Самый факт, что РОР популярен уже говорит, что быстродействие — это не то, что стоит рассматривать именно сейчас как важную фичу. Быстродействие будет лучше. By design. Если окажется, что "недостаточно лучше", то можно будет заняться оптимизацией.

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


А что потом делать с этими анонимными типами? Нужны алгебраические типы.

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

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

Кто-то запретил прототипы накидывать?
Re[17]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 14:36
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Покажи как на C# 4.0 сделать такое:

Z>
Z>        public Index() : ActionResult {
Z>            using (def db = Db())
Z>            {
Z>                ViewData["Message"] = $"NRails env: '$(db.Env)'. We have $(db.Persons.Count()) persons."; 
Z>                ViewData["Taxonomies"] = db.Doctors.Select(d => d.Taxonomy).ToList();
Z>            }
            
Z>            View()
Z>        }
Z>// где
Z>  [DatabaseManager]
Z>  class Db: DbManager {}
Z>  [Model]
Z>    public class Doctor    {}
Z>

Z>Это уже работает у меня.

Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.

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

Z>Если бы всех устраивал рор, asp.net mvc был бы никому не нужной безделицей.

Преимущество асп-нета перед РОРом — это собственно .NET. Это на мой взгляд, а на твой? Люди бегут из РОРа потому что их пугает динамика?
Re[6]: Nemerle on rails
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 12.04.10 16:45
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>1) эскейпим по разному, в зависимости от того, куда попала наша строка (см., например, microsoft anti-xss library на codeplex)



H>А не имеет ли смыл идея сделать специальный тип для эскейпнутых строк? Т.е. эскейпинг строки становится просто операцией приведения типа String в EscapeString. Там где нужен эскейпинг методы будут принимать второй тип, а там где он не обязателен — стандартный string.


Имеет. Но типов эскейпнутых строк должно столько, сколько существует различных мест, куда может попасть такая строка (заголовки HTTP, снаружи атрибута HTML, внутри атрибута HTML, в Javascript, CSS и т.п.), т.к. эскпейпить там нужно различными способами.
... << RSDN@Home 1.2.0 alpha 4 rev. 1446>>

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[14]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 18:50
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Супер! Тогда закругяемся. Только не забудь отписать ребятам из МС которые пишут MVC, что они олухи и не додумались до таких простых решений .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 18:51
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Конечно, это не РОР, за которым стоит бабло Эпла,


Какого еще Эпла?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 18:59
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная.


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

Считаешь что динамика круче. Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет.

ВВ>В РОР по определению никаких статических проверок, и людям это нравится.


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

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


Создай тему в философии — обсуди эту тему, если она тебе интересна. Мне вот она не интересна. У меня даже сомнений нет, что статика всегда лучше динамики, так как чем раньше будет выявлена ошибка тем лучше. Главное, чтобы статика не делала софт менее функциональным и удобным.

Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у.

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


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

В общем, дай человеку хоть что-то сделать. Не топи порыв энтузиазма в гнилой философии!
Пойми, я тоже обожаю по-филосовствовать. Но нужно где-то остановиться. В какой-то момент философия теряет смысл и становится бессмысленным давлением на моги окружающих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 19:04
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


ВВ>А что потом делать с этими анонимными типами? Нужны алгебраические типы.


Вот здесь — согласен!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 12.04.10 19:19
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Максимум что можно делать с анонимными типами (те, что изготавливаются в теле методов) — это представить их в виде иммутабельной key-value коллекции, что собственно и было сделано: немерловый анонимный тип (аналогичный C#) реализует интерфейс Nemerle.Extensions.IAnonymous, это ничем не лучше ViewData.

Кто-нибудь покажет как можно алгебраические типы использовать для передачи "модели" в "представление")?
/* иЗвиНите зА неРовнЫй поЧерК */
Re[17]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 19:20
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Я так вижу тут у тебя две задачи: сократить количество ручного кодирования и добавить статические проверки. Первое можно и на C# 4.0, второе — штука неоднозначная.

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

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

VD>Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет.


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

ВВ>>В РОР по определению никаких статических проверок, и людям это нравится.

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

И казалось бы зачем мне шарповые рельсы? Мне вообще не нравится ASP.NET MVC, будь он хоть статический, хоть динамический.

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

VD>Создай тему в философии — обсуди эту тему, если она тебе интересна. Мне вот она не интересна. У меня даже сомнений нет, что статика всегда лучше динамики, так как чем раньше будет выявлена ошибка тем лучше. Главное, чтобы статика не делала софт менее функциональным и удобным.
VD>Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у.

Мне казалось, задача создать фреймворк, который позволяет разрабатывать веб-приложения, используя функциональную парадигму. И не в стиле "здесь ввернем палу лямбд и ФВП", а *целиком*. Будет ли там только статика или статика+динамика или еще как-то — вообще вопрос вторичный.

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

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

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

VD>В общем, дай человеку хоть что-то сделать. Не топи порыв энтузиазма в гнилой философии!

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

А он и так делает, никто порыв не топит.
Если мои скромные и аккуратные ремарки способны утопить порыв, то видимо никакого порыва и не было.
Re[13]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 19:41
Оценка:
Здравствуйте, VladD2, Вы писали:

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

ВВ>>А что потом делать с этими анонимными типами? Нужны алгебраические типы.
VD>Вот здесь — согласен!

А с чем не согласен? Тебе хочется хочется "более статически-типизированного" ASP.NET MVC?

Вот только там:
— нет декларативной валидации
— генерации вьюх это текстовый шаблон
— для простых случаев есть дикая redundancy в описаниях модели
и так далее и тому подобное

И как только мы введем ADT — ведь и модель должна быть представлена как ADT, наверное — это кардинально изменит просто все.
Re[12]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 19:52
Оценка: +1
Здравствуйте, hardcase, Вы писали:

H>Кто-нибудь покажет как можно алгебраические типы использовать для передачи "модели" в "представление")?


А что показыать то? Их нужно как-то генерировать, потом генерирвоать их конструктор и т.п.

В общем-то их можно получить прямо в запросах к БД. Или настроить некоторое отображение для них.

Короче, тут концепцию нужно продумать. Что от куда берем, в какм виде, куда передаем, как обрабатываем?...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 19:57
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>А что потом делать с этими анонимными типами? Нужны алгебраические типы.

VD>>Вот здесь — согласен!

ВВ>А с чем не согласен?


С тем, что варианты — хорошее предсавление для многих вещей.

ВВ>Тебе хочется хочется "более статически-типизированного" ASP.NET MVC?


И это тоже.

ВВ>Вот только там:

ВВ>- нет декларативной валидации

И сделать нельзя?

ВВ>- генерации вьюх это текстовый шаблон


Плохо. Тут как раз нужен ДСЛ который бы работал с некой объектной моделью — View AST.

ВВ>- для простых случаев есть дикая redundancy в описаниях модели


Устраним.

ВВ>и так далее и тому подобное


Устраним.

ВВ>И как только мы введем ADT — ведь и модель должна быть представлена как ADT, наверное — это кардинально изменит просто все.


Хз. Надо думать. Вот то что формат View лучше оформить в виде вариантов я вижу уже отчетливо. Ее тогда можно будет удобно трансформировать и контролировать корректность выходного формата. Плюс весь эскейпинг можно на это дело повесить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.04.10 20:06
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я не считаю, что "динамика круче". Я вообще не оперирую такими понятиями как "круче" или "некруче".

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

А я считаю, что динамика — это почти всегда зло. Иногда, конечно, необходимо. Но если можно без нее, то нужно без нее. Динамическая компиляция — 100% лучше чем динамическая типизация.

VD>>Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет.


ВВ>Если ты "долго наблюдаешь за мной", то наверное должен был бы заметить, что "это" совсем не то, что я хочу.


Тогда опиши что ты хочешь. Но зачем навязывать человеку свою идеологию?

ВВ>И казалось бы зачем мне шарповые рельсы? Мне вообще не нравится ASP.NET MVC, будь он хоть статический, хоть динамический.


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

VD>>Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у.


ВВ>Мне казалось, задача создать фреймворк, который позволяет разрабатывать веб-приложения, используя функциональную парадигму. И не в стиле "здесь ввернем палу лямбд и ФВП", а *целиком*. Будет ли там только статика или статика+динамика или еще как-то — вообще вопрос вторичный.


Ну, кому-то из нас точно что-то казалось. Я ФП рассматриваю как инструмент позволяющий решать задачи, а не как смоцель. Мне важна декларативность. А уж как ее достичь дело десятое.

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

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

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


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

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

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


Ты не верно понимаешь суть термина "ранатйм-проверка".

ВВ>А он и так делает, никто порыв не топит.


Слава богу! Другой бы офигел и бросил бы.

ВВ>Если мои скромные и аккуратные ремарки способны утопить порыв, то видимо никакого порыва и не было.


Надо знать меру.

Я вот тоже не в востроге, что мои идеи по реструктуризатору были отброшены. Но это его решение! И его реализация. Возможно первый блин будет комом, но он (и окружающие) получат опыт. Причем не эфимерный, а в виде реально работающего кода. И вот кода этот код можно будте хотя бы запустить в тестовом режиме, то можно убдет сказать что-то конкретное.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 20:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А я считаю, что динамика — это почти всегда зло. Иногда, конечно, необходимо. Но если можно без нее, то нужно без нее.


А откуда это утверждение? Дотнет хорош не в последнюю очередь благодаря как раз большим чисто динамическим возможностям. Статическая типизация означает, что часть проверок — всего лишь часть — выносится в компайл-тайм. Я же не против этого. Мне кажется неразумным отказываться от любой динамики в принципе, только потому что "это плохо".
Вам хочется DRY/DIE и статику, а мне хочется REPL

VD>Динамическая компиляция — 100% лучше чем динамическая типизация.


Ну я, честно говоря, с трудом себе представляю динамическую компиляцию для *всего* веб-решения.

VD>>>Пойди реализуй то что ты хочешь на C# 4.0. Благо он сегодня уже вышел в свет.

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

Я хочу, чтобы если уж у нас и был бы MVC, то даже чисто теоретически View мог бы быть только View, и вся работа с данными всегда осуществлялась бы через контроллер, и чтобы это нельзя было сломать, даже если бы захотелось.
Я не хочу HTML как текста, хочу ДСЛ, HTML литералы, называй как хочешь.
Я не хочу class based OOP для описания бизнес-объектов, хочу ADT.
Я хочу декларативную валидацию.
Я хочу, чтобы между клиентом и сервером не было такой пропасти, и чтобы одинаковые задачи решались одинаково.
Ну и ДжаваСкрипт меня подзадолбал, если честно.

VD>Но зачем навязывать человеку свою идеологию?


Ну вообще-то я просто пытался понять *его* идеологию.

ВВ>>И казалось бы зачем мне шарповые рельсы? Мне вообще не нравится ASP.NET MVC, будь он хоть статический, хоть динамический.

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

У меня нет противоречий, я просто не придерживаюсь точки зрения типа "Х это плохо 100% случаев". Сформированной концепции у меня нет, только "хотелки".

VD>>>Как я понял цель проекта как раз получить статическую типизацию при сохранении простоты и удобства разработки сайтов присущих РОР-у.

ВВ>>Мне казалось, задача создать фреймворк, который позволяет разрабатывать веб-приложения, используя функциональную парадигму. И не в стиле "здесь ввернем палу лямбд и ФВП", а *целиком*. Будет ли там только статика или статика+динамика или еще как-то — вообще вопрос вторичный.
VD>Ну, кому-то из нас точно что-то казалось. Я ФП рассматриваю как инструмент позволяющий решать задачи, а не как смоцель. Мне важна декларативность. А уж как ее достичь дело десятое.

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

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

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

Да ради бога, переопределил у тебя кто-нибудь оператор + и стал у тебя компилироваться код, который складывает Foo и Bar. Что значит корректно/некорректно?
Зачастую нам на этапе компиляции известно не какие операции можно совершать над типом, а какие контракты этот тип реализует. А свалится ли он при каком-нибудь ConvertToInt32 — известно только в рантайме.
Не та эта область ИМХО, чтобы шашкой махать. У тебя все равно куча вещей, которые вылезут в рантайме только. А динамическая типизация ведь и плюсы свои дает.

VD>И сообщение будет весьма специфическим.


Э, а в чем "специфичность"?
Пишем на Руби:

x = 2
y = "str"
puts x + y


Ошибка:

C:/temp/ruby.rb:ХХ:in `+': String can't be coerced into Fixnum (TypeError)


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

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

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

ВВ>>А он и так делает, никто порыв не топит.

VD>Слава богу! Другой бы офигел и бросил бы.

А что я такого сказал-то?
Я был предельно вежлив, с пеной у рта ничего не доказывал. Даже не знаю, как еще можно.
Re[15]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 21:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ВВ>>>>А что потом делать с этими анонимными типами? Нужны алгебраические типы.

VD>>>Вот здесь — согласен!
ВВ>>А с чем не согласен?
VD>С тем, что варианты — хорошее предсавление для многих вещей.

В смысле ты с этим не согласен?

ВВ>>Тебе хочется хочется "более статически-типизированного" ASP.NET MVC?

VD>И это тоже.

Зачем тебе вообще MVC?
Если сделать все наши хотелки, от него останутся рожки да ножки.

ВВ>>Вот только там:

ВВ>>- нет декларативной валидации
VD>И сделать нельзя?

Как? Надо думать. В ХМЛ-е это by design как бы.
По идее должен быть "формат" специфицирующий модель. Это могут быть и метаданные самих ADT модели.

ВВ>>- генерации вьюх это текстовый шаблон

VD>Плохо. Тут как раз нужен ДСЛ который бы работал с некой объектной моделью — View AST.

А ты Ur/Web смотрел?

ВВ>>И как только мы введем ADT — ведь и модель должна быть представлена как ADT, наверное — это кардинально изменит просто все.

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

Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.
Re[20]: Nemerle on rails
От: hardcase Пират http://nemerle.org
Дата: 12.04.10 21:15
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Ну и скомпилирует тебе веб-сервер для каждой открытой aspx страницы временную динамическую сборку.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[21]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 12.04.10 21:18
Оценка:
Здравствуйте, hardcase, Вы писали:

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

ВВ>>В АСП.НЕТ, к слову, именно такая модель. Компиляции как таковой нет. Если хочешь — можешь запустить валидацию. Не хочешь — сразу открывай в браузере.
H>Ну и скомпилирует тебе веб-сервер для каждой открытой aspx страницы временную динамическую сборку.

И что сказать-то хотел?
Re[18]: Nemerle on rails
От: Ziaw Россия  
Дата: 13.04.10 00:51
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Z>>Покажи как на C# 4.0 сделать такое:

Z>>
Z>>        public Index() : ActionResult {
Z>>            using (def db = Db())
Z>>            {
Z>>                ViewData["Message"] = $"NRails env: '$(db.Env)'. We have $(db.Persons.Count()) persons."; 
Z>>                ViewData["Taxonomies"] = db.Doctors.Select(d => d.Taxonomy).ToList();
Z>>            }
Z>>            View()
Z>>        }
Z>>// где
Z>>  [DatabaseManager]
Z>>  class Db: DbManager {}
Z>>  [Model]
Z>>    public class Doctor    {}
Z>>

Z>>Это уже работает у меня.

ВВ>Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.

Это полный пример. Лопату выделил. Класс модели Person только упустил, он один в один как Doctor. Расскажи как это делается на динамиках.

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

Z>>Если бы всех устраивал рор, asp.net mvc был бы никому не нужной безделицей.

ВВ>Преимущество асп-нета перед РОРом — это собственно .NET. Это на мой взгляд, а на твой? Люди бегут из РОРа потому что их пугает динамика?


Не бегут из рельсов, а программируют в веб на статически типизированных языках.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[19]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 13.04.10 09:24
Оценка: 1 (1)
Здравствуйте, Ziaw, Вы писали:

ВВ>>Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.

Z>Это полный пример. Лопату выделил. Класс модели Person только упустил, он один в один как Doctor. Расскажи как это делается на динамиках.

Ну ты расскажи для начала как это у тебя делается. В C# — очень просто. Я захожу, открываю дизайнер, перетаскиваю мышкой таблички Person, Doctor и пр. на диаграмму. После этого у меня все появляется. И без всяких динамиков. И как бы получается, что дизайн-тайм генерация тут не особо хуже макросов.

А с помощью IDynamicObject можно попросту генерировать в рантайме.

Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.

Не та эта область, где макросы рулят. Вот, к примеру, написать компилятор Си-шарпа в ДжаваСкрипт без макросов будет гораздо сложнее.
Re[20]: Nemerle on rails
От: Ziaw Россия  
Дата: 13.04.10 10:06
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>Э, а можно более полный пример? Я тут что-то вообще "лопаты" не вижу.

Z>>Это полный пример. Лопату выделил. Класс модели Person только упустил, он один в один как Doctor. Расскажи как это делается на динамиках.

ВВ>Ну ты расскажи для начала как это у тебя делается.

http://code.google.com/p/nemerleonrails/wiki/Progress

ВВ>В C# — очень просто. Я захожу, открываю дизайнер, перетаскиваю мышкой таблички Person, Doctor и пр. на диаграмму. После этого у меня все появляется. И без всяких динамиков. И как бы получается, что дизайн-тайм генерация тут не особо хуже макросов.


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

ВВ>А с помощью IDynamicObject можно попросту генерировать в рантайме.


Ты уверен, что получится сделать db.Doctors.Select(d => d.Taxonomy).ToList() на динамиках?

ВВ>Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.


Я ней пойму чем этот билд провайдер поможет при разработке. Ты клонишь в сторону генерации кода типа T4 чтоли? Спасибо, обойдусь.

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


Ага, а в .NET доказывают, что макры для генерации кода на порядок удобнее шаблонов автогенерации, кому верить?
Re[21]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 13.04.10 10:29
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Чет, ты загнул. Ты Linq2Sql использовал? Дизайнер есть дизайнер, мне оно не особо нравится, но людям нравится. И ничего там грохать не надо, вполне нормально все с базой синхронизируется.

ВВ>>А с помощью IDynamicObject можно попросту генерировать в рантайме.

Z>Ты уверен, что получится сделать db.Doctors.Select(d => d.Taxonomy).ToList() на динамиках?

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

ВВ>>Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.

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

Билд провайдер — еще один вариант генерить код (не текст) по некоторому ДСЛ-ю. Это то, что есть конкретно в АСП.НЕТ и то, что собирались, но так и не добавили в компилятор Шарпа. Это весьма мощная штука. Билд-провайдер не "текст" генерит, он сборки генерит.
Вообще у меня складывается впечатление, что ты не слышал об этом механизме. Если я не прав — no offense. Если все же не слышал — почитай, это весьма интересная штука, знать о ней дело не лишнее:
http://www.pluralsight-training.net/community/blogs/fritz/archive/2004/09/06/2188.aspx

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

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

Не понял. Я вроде тоже самое сказал.
Re[22]: Nemerle on rails
От: Ziaw Россия  
Дата: 13.04.10 10:45
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

Z>>Ты уверен, что получится сделать db.Doctors.Select(d => d.Taxonomy).ToList() на динамиках?


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


Я точно не смогу, экспрешн там не динамик, ему надо вывести тип Doctor -> string, а не из чего. Даже без экспрешена это будет просто набор буковок, как в РоР, так я лучше РоР и заюзаю, для него эти проблемы хоть нормальными IDE решаются.

ВВ>>>Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.

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

ВВ>Билд провайдер — еще один вариант генерить код (не текст) по некоторому ДСЛ-ю. Это то, что есть конкретно в АСП.НЕТ и то, что собирались, но так и не добавили в компилятор Шарпа. Это весьма мощная штука. Билд-провайдер не "текст" генерит, он сборки генерит.

ВВ>Вообще у меня складывается впечатление, что ты не слышал об этом механизме. Если я не прав — no offense. Если все же не слышал — почитай, это весьма интересная штука, знать о ней дело не лишнее:
ВВ>http://www.pluralsight-training.net/community/blogs/fritz/archive/2004/09/06/2188.aspx

Не слышал, почитал ссылку, так и не понял чем "yes, you have to use the CodeDom" лучше T4.

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

ВВ>Не понял. Я вроде тоже самое сказал.

Тогда я не пойму, зачем ты меня уже в который раз отговариваешь от макров в пользу CodeDom и T4?
Re[23]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 13.04.10 10:58
Оценка:
Здравствуйте, Ziaw, Вы писали:

ВВ>>Билд провайдер — еще один вариант генерить код (не текст) по некоторому ДСЛ-ю. Это то, что есть конкретно в АСП.НЕТ и то, что собирались, но так и не добавили в компилятор Шарпа. Это весьма мощная штука. Билд-провайдер не "текст" генерит, он сборки генерит.

ВВ>>Вообще у меня складывается впечатление, что ты не слышал об этом механизме. Если я не прав — no offense. Если все же не слышал — почитай, это весьма интересная штука, знать о ней дело не лишнее:
ВВ>>http://www.pluralsight-training.net/community/blogs/fritz/archive/2004/09/06/2188.aspx
Z>Не слышал, почитал ссылку, так и не понял чем "yes, you have to use the CodeDom" лучше T4.

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

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

ВВ>>Не понял. Я вроде тоже самое сказал.
Z>Тогда я не пойму, зачем ты меня уже в который раз отговариваешь от макров в пользу CodeDom и T4?

Про Т4 я вообще ничего не говорил. От макросов я тебя не отговариваю. Я лишь говорю, что здесь Немерле не предоставляет какие-то эксклюзивные возможности. И то, что ты делаешь, делается и без Немерле. А модели сейчас вообще модно с визуальных ДСЛ-ей создавать — DSL Toolkit.

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

Я просто говорю, что при таком подходе вся мощь Немерле как-то за кадром остается.
Re[24]: Nemerle on rails
От: Ziaw Россия  
Дата: 13.04.10 14:37
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


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

ВВ>Про Т4 я вообще ничего не говорил. От макросов я тебя не отговариваю. Я лишь говорю, что здесь Немерле не предоставляет какие-то эксклюзивные возможности. И то, что ты делаешь, делается и без Немерле.


Ну конечно, DSL для миграций тоже делается своим парсером, не проблема. View engine тоже делается, надо только аддон к студии, не проблема. Что там еще, t4mvc тоже делает почти все что я задумал в одном из пунктов.

ВВ>А модели сейчас вообще модно с визуальных ДСЛ-ей создавать — DSL Toolkit.


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

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


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

ВВ>Я просто говорю, что при таком подходе вся мощь Немерле как-то за кадром остается.


Огласи сразу список мощей немерле которые я не буду использовать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[20]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.04.10 23:58
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


VD>>А я считаю, что динамика — это почти всегда зло. Иногда, конечно, необходимо. Но если можно без нее, то нужно без нее.


ВВ>А откуда это утверждение?


Тебе нужен адрес где я живу?

Это мое утверждение. Вывод сделан на базе опыта.

VD>Дотнет хорош не в последнюю очередь благодаря как раз большим чисто динамическим возможностям.


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

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


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

ВВ>Вам хочется DRY/DIE и статику, а мне хочется REPL


Ну, значит у тебя свой путь. Я лично не очень люблю Репл. Хотя конечно иметь возможность подправить функцию и продолжить выполнение — это очень удобно. Но это тот же шарп позволяет и без динамики. Жаль что так еж нельзя в Немерле и так же нельзя с классами.

VD>>Динамическая компиляция — 100% лучше чем динамическая типизация.


ВВ>Ну я, честно говоря, с трудом себе представляю динамическую компиляцию для *всего* веб-решения.


А для его частей представляешь?

ВВ>Я хочу, чтобы если уж у нас и был бы MVC, то даже чисто теоретически View мог бы быть только View, и вся работа с данными всегда осуществлялась бы через контроллер, и чтобы это нельзя было сломать, даже если бы захотелось.


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

ВВ>Я не хочу HTML как текста, хочу ДСЛ, HTML литералы, называй как хочешь.


Я тоже. Не знаю только нужны ли HTML-литералы или хватит XML-литералов.

ВВ>Я не хочу class based OOP для описания бизнес-объектов, хочу ADT.


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

ВВ>Я хочу декларативную валидацию.


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

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


Ну, это слишком абстрактно. Но я тоже за мир во всем мире!

ВВ>Ну и ДжаваСкрипт меня подзадолбал, если честно.


Бывает. Меня сея чаша обошла стороной, к счастью.

Только причем тут динамическая типизация?

VD>>Но зачем навязывать человеку свою идеологию?


ВВ>Ну вообще-то я просто пытался понять *его* идеологию.


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

ВВ>У меня нет противоречий, я просто не придерживаюсь точки зрения типа "Х это плохо 100% случаев". Сформированной концепции у меня нет, только "хотелки".


Ну, вот они и выглядят как сумбур. Причем когда они в декларативном виде, то все еще ничего. А когда к ним примешиваются идеи по реализации... то и появляются эти разговоры про динамику.

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


Опиши конкретные примеры того о чем ты говоришь.

ВВ>Да ради бога, переопределил у тебя кто-нибудь оператор + и стал у тебя компилироваться код, который складывает Foo и Bar. Что значит корректно/некорректно?


Пошла какая-то общая софистика...

ВВ>Зачастую нам на этапе компиляции известно не какие операции можно совершать над типом, а какие контракты этот тип реализует. А свалится ли он при каком-нибудь ConvertToInt32 — известно только в рантайме.


Это ошибочная точка зрения насаждаемая современным ООП. На самом деле код должен быть построен так, чтобы даже если ConvertToInt32 не прошел, то приложение все равно корректно продолжило бы работу. Например, выдав сообщение об ошибке (валидация в твоем понимании).

ВВ>Не та эта область ИМХО, чтобы шашкой махать. У тебя все равно куча вещей, которые вылезут в рантайме только. А динамическая типизация ведь и плюсы свои дает.


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

ВВ>Я верно понимаю суть термина "проверка". Если нужные тебе проверки можно сделать до запуска на исполнение, значит искомая цель достигнута. Разве нет?


А зачем мне проверять вручную то, что может проверить компилятора в автомате?

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


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

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


К слову, до сих пор считаю, что код-бихаинд очень правильный подход. Правда не потомоу, что он более статически типизирован, а потому, что он отделяет представление от логики и позволяет дизайнеру заняться дизайном, а программисту функционалом. (да, знаю о том, что не все там чисто и пушисто, но это опять же идеал...).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 00:04
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

VD>>С тем, что варианты — хорошее предсавление для многих вещей.


ВВ>В смысле ты с этим не согласен?


Со своими высказываниями? Почти всегда!

ВВ>Зачем тебе вообще MVC?

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

Хз. Я с MVC не знаком.

ВВ>>>Вот только там:

ВВ>>>- нет декларативной валидации
VD>>И сделать нельзя?

ВВ>Как? Надо думать. В ХМЛ-е это by design как бы.


А схемы на что?

ВВ>По идее должен быть "формат" специфицирующий модель.


Ну, дык а разве модель в линке — это не тоже самое?

ВВ>Это могут быть и метаданные самих ADT модели.


Очень абстрактно. Я бы с удовольствие послушал об этой идее по подробнее.

ВВ>А ты Ur/Web смотрел?


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

ВВ>Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.


Значит так. Данные у нас в БД. Первый уровень абстракции от БД у нас — это модель Линка — проекция то есть.

Преимущества такого подхода в гибкости выборки данных.

Где и зачем здесь роль АлгТД? И как ты видишь преобразование данных БД (или линка) в АлгТД?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 00:09
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Кому оба эти варианта не нравится — можно сделать асп-нет билд-провайдер. Опять-таки сделает то же самое, что и макрос. С тем же уровнем юзабилити.


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

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

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


Это не не та, а не только так. То что ты хочешь тоже здорово. Но не только это здорово.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 14.04.10 00:30
Оценка:
Здравствуйте, VladD2, Вы писали:

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

обусловлена условиями задачи, то пусть она будет.

Тогда и основы для спора нет

ВВ>>Вам хочется DRY/DIE и статику, а мне хочется REPL


ВВ>>Ну я, честно говоря, с трудом себе представляю динамическую компиляцию для *всего* веб-решения.

VD>А для его частей представляешь?

Для частей представляю. Но чтобы у меня дата-лаер компилировался динамически... Причем еще сам, если я базу поменял...

ВВ>>Я не хочу class based OOP для описания бизнес-объектов, хочу ADT.

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

Если не будет ADT, как потом анализировать данные? Циклы писать? Или на ОО-манер городить тонны кода? От этого как раз хочется уйти.

ВВ>>Я хочу декларативную валидацию.

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

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

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

VD>Ну, это слишком абстрактно. Но я тоже за мир во всем мире!

Ну вот неабстрактное решение есть в Ur/Web. Ur компилируется в ДжаваСкрипт, причем компилятор сам решает, где должен выполняться метод. Если в нем нет обращений к ресурсам на клиенте, то он будет выполняться на сервере. Если есть, то на клиенте. Если и то, и другое — то на клиенте, а обращение к методам на сервере будет автоматически раскрываться в RPC-вызов.

ВВ>>Ну и ДжаваСкрипт меня подзадолбал, если честно.

VD>Бывает. Меня сея чаша обошла стороной, к счастью.
VD>Только причем тут динамическая типизация?

Собственно, я уже и забыл причем она и тут.

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

VD>Опиши конкретные примеры того о чем ты говоришь.

Весь жизненный этап веб-приложения от "пользователь ввел адрес" до "пользователь увидел страницу" можно описать как цепочку трансформаций: получаем данные в формате Х, преобразуем их в формат У и так далее. Базовые средства АСП.НЕТ никак эту задачу не упрощают, АСП.НЕТ вообще начался с того, что мы решили прикидываться, как будто у нас приложение на десктопе крутится. Лучше всего для этих вещей подходит XSLT, но у него тоже есть очевидные проблемы.

VD>Это ошибочная точка зрения насаждаемая современным ООП. На самом деле код должен быть построен так, чтобы даже если ConvertToInt32 не прошел, то приложение все равно корректно продолжило бы работу. Например, выдав сообщение об ошибке (валидация в твоем понимании).


Во, правильно. Прямо как в динамических языках. Не прошло, проверил, выдал сообщение об ошибке
Блин, опять я...

ВВ>>Не та эта область ИМХО, чтобы шашкой махать. У тебя все равно куча вещей, которые вылезут в рантайме только. А динамическая типизация ведь и плюсы свои дает.

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

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

ВВ>>Я верно понимаю суть термина "проверка". Если нужные тебе проверки можно сделать до запуска на исполнение, значит искомая цель достигнута. Разве нет?

VD>А зачем мне проверять вручную то, что может проверить компилятора в автомате?

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

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

VD>Не придумывай. Компиляция динамическая, но она есть.

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

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

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

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

Потом я неправильно высказался, под коде-бехаиндом я имел в виду то время, когда студия насильно компилировала все в ДЛЛ, хотя АСП.НЕТ с самого начала поддерживал как коде-инсайт, так и коде-бехаинд без всякой предкомпиляции — просто положил рядом файлик с кодом и все.
Re[17]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 14.04.10 00:42
Оценка:
Здравствуйте, VladD2, Вы писали:


ВВ>>Как? Надо думать. В ХМЛ-е это by design как бы.

VD>А схемы на что?

Какие схемы? Ты про XSD? Ну я их и имел в виду. Или ты хочешь их же и использовать?

ВВ>>По идее должен быть "формат" специфицирующий модель.

VD>Ну, дык а разве модель в линке — это не тоже самое?

Модели будет мало.

ВВ>>Это могут быть и метаданные самих ADT модели.

VD>Очень абстрактно. Я бы с удовольствие послушал об этой идее по подробнее.

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

| Person([CtrRange(1, 20)] age : int)

ВВ>>Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.

VD>Значит так. Данные у нас в БД. Первый уровень абстракции от БД у нас — это модель Линка — проекция то есть.
VD>Преимущества такого подхода в гибкости выборки данных.
VD>Где и зачем здесь роль АлгТД?

Зачем — для анализа через матчи.

VD>И как ты видишь преобразование данных БД (или линка) в АлгТД?


По большому счету ADT тут ничем не отличается (ну почти) не отличается от обычных классов. Их точно также можно генерить. Например, вся база может быть представлена в виде единого ADT.
Re[22]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 01:14
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Для частей представляю. Но чтобы у меня дата-лаер компилировался динамически... Причем еще сам, если я базу поменял...


А зачем это надо?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 14.04.10 01:16
Оценка:
Здравствуйте, VladD2, Вы писали:

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

ВВ>>Для частей представляю. Но чтобы у меня дата-лаер компилировался динамически... Причем еще сам, если я базу поменял...
VD>А зачем это надо?

Опять же — REPL. Надо при разработке, особенно в R&D стиле, тестировании, поиске хитрожопых багов. Ну обычные преимущества репла.
При статике это конечно не имеет смысла.
Re[18]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 01:22
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Какие схемы? Ты про XSD? Ну я их и имел в виду.


Ага.

ВВ>Или ты хочешь их же и использовать?


Ну, напрямую — нет. Я их плохо знаю и они страшные. Но по сути — да.

ВВ>>>По идее должен быть "формат" специфицирующий модель.

VD>>Ну, дык а разве модель в линке — это не тоже самое?

ВВ>Модели будет мало.


Это ты просто модель очень ограниченно понимаешь.

ВВ>В теории все просто — вводятся специальные макросы или атрибуты (и удобный механизм работы с ними), которые позволяют вешать своего рода констрейнты на отдельные поля. Плюс возможность создания собственных констрейнтов. Констрейнт сам по себе описывается в виде этакого воркфлоу и может быть откомпилирован как в Немерле, так в ДжаваСкрипт. Типа:


ВВ>| Person([CtrRange(1, 20)] age : int)


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

ВВ>>>Модель надо оформить в виде ADT. Вью — это трансформатор. В случае с ХМЛ-ем Вью — это XSLT.

VD>>Значит так. Данные у нас в БД. Первый уровень абстракции от БД у нас — это модель Линка — проекция то есть.
VD>>Преимущества такого подхода в гибкости выборки данных.
VD>>Где и зачем здесь роль АлгТД?

ВВ>Зачем — для анализа через матчи.


Самоцель?


VD>>И как ты видишь преобразование данных БД (или линка) в АлгТД?


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


Что-то я не вижу в этом смысла. Ну, может просто спать пора.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.04.10 01:24
Оценка:
Здравствуйте, Воронков Василий, Вы писали:


ВВ>Опять же — REPL. Надо при разработке, особенно в R&D стиле, тестировании, поиске хитрожопых багов. Ну обычные преимущества репла.

ВВ>При статике это конечно не имеет смысла.

Я точно так же по F5 отлично все это делаю. И в место репла я предпочел бы наличие динамического зименения кода в рантайме (как это сейчас для шарпа делается).

А вот менять что-то без интеллисенса — это не здорово (для меня).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 14.04.10 21:36
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>| Person([CtrRange(1, 20)] age : int)

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

Проверки как правило таки требуют какого-то кода. И возникает вопрос — где должен исполняться это код? На сервере, на клиенте? На каком языке он будет? Поэтому тут скорее нужны цитаты, а не код напрямую.

ВВ>>Зачем — для анализа через матчи.

VD>Самоцель?

Цель — писать меньше кода чем сейчас. По крайней мере одна из.
А что я буду делать с вашими классами? Сейчас я получил классы и запихиваю их в XSLT.

VD>>>И как ты видишь преобразование данных БД (или линка) в АлгТД?

ВВ>>По большому счету ADT тут ничем не отличается (ну почти) не отличается от обычных классов. Их точно также можно генерить. Например, вся база может быть представлена в виде единого ADT.
VD>Что-то я не вижу в этом смысла. Ну, может просто спать пора.

А какой смысл ты видишь в генерации ОО-подобной модели по базе?
Re[20]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 02:17
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А какой смысл ты видишь в генерации ОО-подобной модели по базе?


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

Варинаты — это полиморфизм. Если у нас будут полиморфные таблицы, то варианты можно будет отобразить на них. А так, я не вижу внятного объяснения применения вариантов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 11:08
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

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

VD>Варинаты — это полиморфизм. Если у нас будут полиморфные таблицы, то варианты можно будет отобразить на них. А так, я не вижу внятного объяснения применения вариантов.


Что такое "полиморфные таблицы" мне непонятно. На уровне классической реляционной БД никакого полиморфизма нет. Полиморфизм это то, что появляется в мозгах у программиста, когда он делает отображение базы на "что-то еще". Если "что-то еще" это анемичная модель, то полиморфизма как не было, так и не будет. А если это, скажем, ХМЛ, то полиморфны будут *все* структуры (но при этом по-прежнему статически типизированы).

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

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

Моя мысль бьется, так сказать, в одном направлении — аналог XML/XSD/XSLT, но без XML.
Re[22]: Nemerle on rails
От: Ziaw Россия  
Дата: 15.04.10 13:40
Оценка: :)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Если вы что-то кардинально иное предлагаете, то я хочу понять что. Я пока не понял. Если речь о шаблонах на манер ASP, то их не спасет даже лаконичность и строго-типизированность Немерле, ибо просто убоги. Если какой-то альтернативный механизм — то как он будет выглядеть и работать?


Убогость надо обосновать. Покажи задачу и ее решение на xslt который будет выглядеть убого при переложении на шаблоны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 15:51
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Создал проект http://code.google.com/p/nemerleonrails/

Z>В связи с этим возник вопрос:

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

Кстати, где можно взять локальную версию MS SQL 2008?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 16:26
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Убогость надо обосновать. Покажи задачу и ее решение на xslt который будет выглядеть убого при переложении на шаблоны.


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

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

Вопрос только в том, что ХСЛТ трансформирует дервево (ХМЛ) в текст. Но тут есть два вопроса. Во-первых, у нас на входе реляционные данные, а не дерево и нужно подумать о их преобразовании. А во-вторых, лучше на выходе иметь не текст, а что-то типизированное, что можно формально проверить. Хотя бы тот же ХМЛ. А лучше дерево состоящее из типизированных объектов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 16:43
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

Подумалось...

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

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

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

Получается четырехступенчатая схепа:
Данные в БД => Списки записей (получаемые с помощю запросов) => Данные документа (дерево) => ХМЛ или ХТМЛ (конечный разультат).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 16:45
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>Убогость надо обосновать. Покажи задачу и ее решение на xslt который будет выглядеть убого при переложении на шаблоны.

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

ASPX — это по сути императивный текстовый шаблон. XSLT — функциональный язык со всеми отсюда вытекающими. DRY там достигается легко и просто за счет банальной декомпозиции функций да и трансформация по сути описывается через ФВП. Можно сказать, что типичная трансформация — это этакая свертка дерева.
Именно это-то и наводит на мысли. XSLT начинает рулить именно благодаря своей функциональности (это при его весьма сильной ограниченности как языка).

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


Это да.

VD>Вопрос только в том, что ХСЛТ трансформирует дервево (ХМЛ) в текст.


Не совсем так, XSLT трансформирует одно дерево в другое дерево. Т.е. там есть определенный статический контроль. В общем случае ты не можешь сгенерить невалидный XML (это, кстати, весьма хорошо). И XML для XSLT процессора текстом естественно не является.
Есть правда xsl:text — но это как бы узаконенный хак.

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


Ну вот все мои мысли по этому поводу пока приводят меня к тому, что реляционные структуры проще всего преобразовывать именно в ADT.
Альтернатива — ввести какие-то специальные типы данных Но тогда хотелось бы и "специальные" паттерны для них.

VD>А во-вторых, лучше на выходе иметь не текст, а что-то типизированное, что можно формально проверить. Хотя бы тот же ХМЛ. А лучше дерево состоящее из типизированных объектов.


Как я уже сказал, то, что генерит XSLT — типизировано. Ты не сможешь сгенерить даже XML с левыми схемами. Т.е. по идее можно ввести специальные HTML/XML литералы для достижения подобного эффекта.
Re[22]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 16:52
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Так называемые записи — кортежи с именованными полями.

ВВ>ОК, в каком-то плане это еще хуже, т.к. если бы это были полиморфные структуры их можно было бы анализировать используя техники ООП, а так у нас выбор сужается.


Это не хуже или лучше — это данность. Ты правильно заметил, что в БД лежат не объекты. В БД лежат записи!

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

ВВ>Каким образом будет строиться трансформация?

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

ВВ>Что такое "полиморфные таблицы" мне непонятно. На уровне классической реляционной БД никакого полиморфизма нет.


Ну, да. В таблицах все строится на отношениях и соединениях. Так же как в БД нет объектов, но мы можем отобразить записи БД на упрощенные объекты (записи ЯП), точно так же мы можем отобразить некоторый паттерн в БД на некоторый вариантный тип данных. Если вмонтировать поддержку такого паттерна в Линк-провайдер или обертку над ним, то можно будет осуществлять полиморфные запросы (которые будут переписываться в запросы с оледенениями или фильтрацией).

Учитывая, что варианты — это не более чем объединение записей мы получаем весьма простую и стройную модель.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 16:56
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Как я уже сказал, то, что генерит XSLT — типизировано. Ты не сможешь сгенерить даже XML с левыми схемами. Т.е. по идее можно ввести специальные HTML/XML литералы для достижения подобного эффекта.


ХМЛ не типизирован. Именно по этому ему нужны схемы для контроля. А типизированному дереву схемы не нужны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 17:00
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Как я уже сказал, то, что генерит XSLT — типизировано. Ты не сможешь сгенерить даже XML с левыми схемами. Т.е. по идее можно ввести специальные HTML/XML литералы для достижения подобного эффекта.

VD>ХМЛ не типизирован. Именно по этому ему нужны схемы для контроля. А типизированному дереву схемы не нужны.

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

Вообще говоря самый простой вариант — это ХМЛ и использовать. Может, и не так уж он и плох. Получаем и формат, по которому валидация будет строиться — XSD. А вместо XSLT сделать свой язык. Ну и ввести XML литералы.
Re[21]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 17:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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

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

Не очень понятно. Как ты будешь их в деревья трансформировать?

Положим у тебя на выходе:

PostId = ..., PostTitle = ..., PostDate = ...

и так n-раз.
Ну и во что мы можем это превратить?

А если так:

PostId = ..., PostTitle = ..., PostDate = ...
CommentId ..., CommentTitle = ..., CommentText = ...
CommentId ..., CommentTitle = ..., CommentText = ...

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

А дерево HTMLя — ну так там чисто визуальные язык разметки. Плоский список превратится в дерево просто потому что он отображается таким образом.
Re[27]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 17:08
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Если тебе без разницы, то пользуйся им.

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

ВВ>Вообще говоря самый простой вариант — это ХМЛ и использовать. Может, и не так уж он и плох. Получаем и формат, по которому валидация будет строиться — XSD. А вместо XSLT сделать свой язык. Ну и ввести XML литералы.


На счет валидации тут еще вопрос. Предпологается использовать модель с генерацией ХТМЛ-я (ну, ХМЛ-я, без разницы). Но эта модель не предполагает автоматической записи изменений. На входе ведь мы получим просто данные. Возможно в виде того же ХМЛ-я. И их сохранением будет заниматься уже отдельный компонент. Стало быть и валидация должна быть реализована как-то в расчете на это.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 17:16
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Не очень понятно. Как ты будешь их в деревья трансформировать?



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

Потенциально и эту задачу можно автоматизировать если создать некоторый ДСЛ отображения.

ВВ>Положим у тебя на выходе:


ВВ>PostId = ..., PostTitle = ..., PostDate = ...


ВВ>и так n-раз.

ВВ>Ну и во что мы можем это превратить?

Плоские данные и превращать не надо.

ВВ>А если так:


ВВ>PostId = ..., PostTitle = ..., PostDate = ...

ВВ> CommentId ..., CommentTitle = ..., CommentText = ...
ВВ> CommentId ..., CommentTitle = ..., CommentText = ...

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

ВВ>То оно вроде и так несильно плоское.

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

Слушай, ты немного утомил. Ты сам то что-то предлагаешь?

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

Как ты себе видишь чтение из БД варианитов? И как при этом получить их иерархию, а не тупой список кортэжей который мы и так имеет?

ВВ>А дерево HTMLя — ну так там чисто визуальные язык разметки. Плоский список превратится в дерево просто потому что он отображается таким образом.


Плоский список отобразить не проблема. На на веб-страницах обычно все сильно сложнее. Та тебе таблицы (да еще и вложенные), разные меню и т.п. В общем — иерархия!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 17:46
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

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


Какой именно информации в моих очках не хватает?

ВВ>>То оно вроде и так несильно плоское.

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

Мне казалось, мы и пытаемся найти решение. Я описываю ту модель, которая уже сейчас на многих задачах работает лучше, чем ASP.NET MVC. Казалось бы остается просто подумать об альтернативах.
Если ты ждешь готовых детально продуманных решений — то их нет у меня.

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

ВВ>>А дерево HTMLя — ну так там чисто визуальные язык разметки. Плоский список превратится в дерево просто потому что он отображается таким образом.

VD>Плоский список отобразить не проблема. На на веб-страницах обычно все сильно сложнее. Та тебе таблицы (да еще и вложенные), разные меню и т.п. В общем — иерархия!

"Разные меню" — это вообще совершенно отдельные, так сказать, единицы трансляции. Не надо все в кучу мешать. Для них вообще могут быть заданы свои правила кэширования.
Re[25]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 18:02
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я точно так же по F5 отлично все это делаю. И в место репла я предпочел бы наличие динамического зименения кода в рантайме (как это сейчас для шарпа делается).


Ты понимаешь в чем проблема F5... В веб-приложении состояние браузер держит. И потому аналогия с РЕПЛом практически полная. Ты дошел до некой точки исполнения (на что ты мог минут -надцать потратить на самом деле), остановился и у тебя нужное состояние держится, и ты можешь с ним экспериментировать, выполнять какой-то код и пр.

Нажать F5 — означает все пройти заново. А что если, у тебя приложение какие-нибудь данные трансформирует/экспортирует, и этот процесс на больших объемах занимает этак с полчаса — а тебе нужно выловить хитрый баг, которые только на таких объемах и проявляется?
Re[24]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 18:17
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


В том, что это дерево — это и есть данные странциы / документа. Скажем чтобы отдать их в виде REST-а или веб-сервиса нужно проделать совсем простенькие операции которые легко можно автоматизировать. Это и может быть тем, что Вольфхаунд называл бэкэндом.

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

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


ВВ>Какой именно информации в моих очках не хватает?


Это была опечатка. В твоих словах...

ВВ>Мне казалось, мы и пытаемся найти решение.


Чтобы найти решение нужно что-то предлагать. И не абстрактное вроде "самолеты переворачивающий и падают" или "представлять данные в виде АлгТД", а конкретные решения поясняемые на конкретных примерах.

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


Да где ты чего описываешь? Или ты считаешь описанием упоминание об использовании ХСЛТ?

ВВ>Если ты ждешь готовых детально продуманных решений — то их нет у меня.


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

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


Да. Обсуждать что-то конкретное, а не пытаться оспорить любые слова собеседника. У меня постоянно создается ощущение, что именно это твоя цель. Но из одних сомнений не может родиться что-то новое.

ВВ>"Разные меню" — это вообще совершенно отдельные, так сказать, единицы трансляции. Не надо все в кучу мешать. Для них вообще могут быть заданы свои правила кэширования.


Возможно... если данные не связаны. Но где-то есть грань разделаюящая данные которые связаны, и те что попали на страницу по каким-то другим соображениям.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.04.10 18:21
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ты понимаешь в чем проблема F5... В веб-приложении состояние браузер держит. И потому аналогия с РЕПЛом практически полная. Ты дошел до некой точки исполнения (на что ты мог минут -надцать потратить на самом деле), остановился и у тебя нужное состояние держится, и ты можешь с ним экспериментировать, выполнять какой-то код и пр.


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


С динамически изменяемым кодом проблем бы не было.

В прочем, для отладки сложных вокфлоу нужны адекватные тесты их воспроизводящие. Так что я бы начал с реализации системы тестирования которая позволяла бы быстро попдать в то состояние что нужно. Или создал бы сериализацию состояния чтобы потом его можно было бы быстро загрузить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 19:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Готовых не жду. Но хотя бы что-то конкретное. Возьми какой-то пример и опиши как бы ты видел его в виде вараинтов или еще как...


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

Если немного пофантазировать...

Я вижу в целом такие задачи:
1. Трансформация исходных данных в новые данные (с целью анализа, расширения данных и пр.)
2. Трансформация данных в HTML-разметку
3. Workflow, которая описывает бизнес-процессы (причем опять-таки в виде некой свертки). При этом есть отдельные сущности — действия (Action, то, что может кодироваться в том числе и императивно, например, создание узла в MOSS с определенным набором грантов) и бизнес-правила (они также являются частью форкфлоу в принципе, однако их выделение в отдельные сущности позволяет сделать воркфлоу более универсальной).

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

На все это накладывается чисто веб-специфика.

1. Кэширование (сервер/клиент)
2. Необходимость хранения данных и организация доступа к ним на уровне сеанса пользователя
3. Необходимость часть кода писать на клиенте, часть на сервере
+ наверняка еще кучу всего забыл

Исходим из того, что итоговая веб-страница логически разделяется на определенные части — назовем их "компонентами", т.к. термин web part уж слишком затаскан. Определяющая характеристика компонента — его автономность. Скажем, для того, чтобы сформировать меню нам совершенно по фигу какое именно количество постов в блоге будет отображаться в этот момент. (Да, я утрирую, но будет считать так для простоты).
Так как они автономны — являются "чистыми" в том смысле, что никак не зависят и не влияют на состояния других компонентов — их формирование может быть легко распараллелено, они могут кэшироваться независимо друг от друга и пр.

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

Попробую пока коснуться только собственно трансформации в HTML.

Исходные данные в удобном формате — это данные в формате, который удобно анализировать. Опять-таки для простоты давайте предпложим, что это ADT, причем данные мы уже волшебным образом получаем в виде:

type MyData = Post | PostComment | Author | ...

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

Компонент описывается в виде отдельной структуры — этакий Translation Unit, — которая состоит из двух частей: логика трансформации и шаблоны.
Логика трансформации — это мач.
"Шаблон" — это функция (возможно, даже компайл-тайм функция), главной особенностью которой является то, что телом функции является не код на Немерле или чем-то еще — а HTML (ну или XML — пока не могу сказать, будет ли здесь серьезная разница) литерал.

— Шаблон всегда возвращает, собственно, XML литерал, причем типизированный (желательно, чтобы по нему тоже можно было мачить по специальному образцу).
— Набор шаблонов сам по себе рассматривается как некая единая структура данных. Т.е. можно считать, что совокупность всех шаблонов компонента формирует новый ADT
— Входным параметром (всегда одним) шаблона является продукция ADT (исходных данных)
— Шаблон может быть перегружен (см. в сторону старого доброго template method), перекрыт или еще как — общая идея в том, чтобы была возможность подменить любой из определенных нами шаблонов.
— Тело шаблона может выглядеть как-нибудь так:

template PostTitle(expr : ...) {
<div id="{exp.Id}">{exp.Title}</div>
}

Мачить по нему можно как-нибудь так: | >PostTitle>div[@Id] -> [массив всех элементов]
(Еще раз повторюсь: CSS селекторы — в лес )

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

Вся логика описывается отдельно в виде квази-цитат. Функции описывающие логику, имеют доступ как к исходным данным (ADT), так и могут рассматривать сам набор шаблон как некий ADT. Функции автоматически транслируются либо в Немерле, либо в ДжаваСкрипт, если они специальным образом помечаются (или просто требуют доступ к чему-то, что существует только на клиенте). Организация взаимодействия клиент-сервер — через REST/JSON.

Да, и конечно *Весь* код лежит в виде "файликов" *.n, компиляция динамическая.
Re[27]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 15.04.10 19:15
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Ну не заставлять же людей писать свои сериализаторы состояние для каждого такого случая? Ведь с РЕПЛом у них таких проблем не будет.
Т.е. по факту — если убирается динамика и РЕПЛ, то должны предоставляться некие "компенсаторы", позволяющие решать те же задачи.
Re[24]: Nemerle on rails
От: Ziaw Россия  
Дата: 16.04.10 00:47
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Шаблон на nemerle тоже поддерживает паттерн матчинг. При этом мне не требуется все данные представлять в виде XML.
Это все плюсы? Посмотри как можно ввести поддержку матчинга в спарк.

<def show tree>
    <ul>
        <match tree>
            <li pattern="Tree.Post(p)" > $!{p.Text} </li>
            <show pattern="Tree.Thread(t)" tree="t">
            <matching pattern="node :: tail">
                <show tree="node">
                <show tree="tail">
            </matching>
        </match>
  <ul>
</def>

<show tree="Model.Forum">


Давай оставим слепые рассуждения об убогости фанатикам и подумаем чего в самом деле не хватает шаблонам.

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


+1

VD>Вопрос только в том, что ХСЛТ трансформирует дервево (ХМЛ) в текст.


В реальных задачах модель в виде дерева не так уж и часта.

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


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

VD>А во-вторых, лучше на выходе иметь не текст, а что-то типизированное, что можно формально проверить. Хотя бы тот же ХМЛ. А лучше дерево состоящее из типизированных объектов.


Вот в этом у меня серьезные сомнения. Для чего проверить? Для безопасности? Xss замаскируется под валидный xml. Вот скажи, какого рода проблемы решит формальная проверка?
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[2]: Nemerle on rails
От: Ziaw Россия  
Дата: 16.04.10 01:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты меня подключи к проекту. Будет время я там подправлю работу с типами и другую мелоч.


Почта какая? vc на рсдн.ру?

VD>Кстати, где можно взять локальную версию MS SQL 2008?


http://www.microsoft.com/sqlserver/2008/ru/ru/express.aspx
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[28]: Nemerle on rails
От: Ziaw Россия  
Дата: 16.04.10 01:21
Оценка: :)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну не заставлять же людей писать свои сериализаторы состояние для каждого такого случая? Ведь с РЕПЛом у них таких проблем не будет.


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

Все что нужно после перезапуска это нажать F5 в браузере.
... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
Re[26]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 10:33
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>ОК, мне в принципе нравится идея Wolfhound на этом этапе вообще не думать про базу. База это база, вопрос отдельный.


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

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

ВВ>Предположим, что у нас уже есть входящие данные в неком удобном для нас формате. Какой же формат нам удобен?


ВВ>Если немного пофантазировать...


ВВ>Я вижу в целом такие задачи:

ВВ>1. Трансформация исходных данных в новые данные (с целью анализа, расширения данных и пр.)
ВВ>2. Трансформация данных в HTML-разметку
ВВ>3. Workflow, которая описывает бизнес-процессы (причем опять-таки в виде некой свертки). При этом есть отдельные сущности — действия (Action, то, что может кодироваться в том числе и императивно, например, создание узла в MOSS с определенным набором грантов) и бизнес-правила (они также являются частью форкфлоу в принципе, однако их выделение в отдельные сущности позволяет сделать воркфлоу более универсальной).

Пункты 1 и 2 — это по сути одно и то же.
Пункт 3 не имеет к первых пунктам ничего общего. Я даже малейшей связи не усматриваю.

ВВ>Поэтому говоря о пути от исходных данных до HTML-разметки речь фактически будет идти об отдельном изолированном компоненте, а не о всем "наборе".


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

Это что-то вроде REST. На вход мы посылаем иерархию данных запакованных в ХМЛ или Джейсон. На выходе — тоже самое... мы получаем другую иерархию. Эта иерархия является ответом пользователя. Ее можно сохранить в БД (и тут как раз и понадобится валидация) или передать другой форме в качестве входных параметров.

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

ВВ>Попробую пока коснуться только собственно трансформации в HTML.


ВВ>Исходные данные в удобном формате — это данные в формате, который удобно анализировать. Опять-таки для простоты давайте предпложим, что это ADT, причем данные мы уже волшебным образом получаем в виде:


ВВ>type MyData = Post | PostComment | Author | ...



В этом описании я вижу кашу из ничем не связанных данных.

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


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

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

ВВ>Логика трансформации — это мач.

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

ВВ>"Шаблон" — это функция (возможно, даже компайл-тайм функция), главной особенностью которой является то, что телом функции является не код на Немерле или чем-то еще


Чем? Опять самолеты...

ВВ>- Шаблон всегда возвращает, собственно, XML литерал, причем типизированный (желательно, чтобы по нему тоже можно было мачить по специальному образцу).


Что такое типизированный XML-литерал?

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


АТД — это абстрактный тип данных. Уж тогда АлгТД. А вообще в немерле это ваниантами называю.

Потом только что у тебя был ХМЛ, теперь АлгТД. Что-то не вижу я продуманной концепции.

ВВ>- Входным параметром (всегда одним) шаблона является продукция ADT (исходных данных)


Во что?

ВВ>- Шаблон может быть перегружен (см. в сторону старого доброго template method),


Может для тебя template method и является старым и добрым, но я вообще не понимаю о чем идет речь.

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

ВВ>- Тело шаблона может выглядеть как-нибудь так:

ВВ>template PostTitle(expr : ...) {

ВВ> <div id="{exp.Id}">{exp.Title}</div>
ВВ>}

И где тут твои АлгТД? Я вижу объекты и что-то вроде стриг-темплэйта.

ВВ>Мачить по нему можно как-нибудь так: | >PostTitle>div[@Id] -> [массив всех элементов]

ВВ>(Еще раз повторюсь: CSS селекторы — в лес )

Мне можешь не повторять. Я их никогда не видел.
Лучше опиши, что означают эти ">PostTitle>div[@Id]" кракозябры? И зачем они вообще нужны?

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


Опять какая-та бессмысленная абстракция.

ВВ>Вся логика описывается отдельно в виде квази-цитат.


Логика чего? К тому же квази-цитаты они как раз для трансформации предназначены.

ВВ> Функции описывающие логику, имеют доступ как к исходным данным (ADT), так и могут рассматривать сам набор шаблон как некий ADT.


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

ВВ> Функции автоматически транслируются либо в Немерле, либо в ДжаваСкрипт, если они специальным образом помечаются (или просто требуют доступ к чему-то, что существует только на клиенте). Организация взаимодействия клиент-сервер — через REST/JSON.


Ну, блин, если REST/JSON (что вообще-то понятия разного порядка), то что у нас тут делают АлгТД?

ВВ>Да, и конечно *Весь* код лежит в виде "файликов" *.n, компиляция динамическая.


А работать с файликами из нотпэда, без комлита и понятия проекта?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 11:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А мне не нравится. Это самый распространенный юзкейс и от того насколько он удобен будет зависеть отношение пользователей.


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

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


И чем это "абстрагироваться" отличается от того Wolfhound предлагает?

ВВ>>Я вижу в целом такие задачи:

ВВ>>1. Трансформация исходных данных в новые данные (с целью анализа, расширения данных и пр.)
ВВ>>2. Трансформация данных в HTML-разметку
ВВ>>3. Workflow, которая описывает бизнес-процессы (причем опять-таки в виде некой свертки). При этом есть отдельные сущности — действия (Action, то, что может кодироваться в том числе и императивно, например, создание узла в MOSS с определенным набором грантов) и бизнес-правила (они также являются частью форкфлоу в принципе, однако их выделение в отдельные сущности позволяет сделать воркфлоу более универсальной).
VD>Пункты 1 и 2 — это по сути одно и то же.

О чем я ниже и написал.

VD>Пункт 3 не имеет к первых пунктам ничего общего. Я даже малейшей связи не усматриваю.


Связь в том, что это средство для решения типичных задач для веба. Под workflow думай больше в сторону WWF.

VD>Это что-то вроде REST. На вход мы посылаем иерархию данных запакованных в ХМЛ или Джейсон. На выходе — тоже самое... мы получаем другую иерархию. Эта иерархия является ответом пользователя. Ее можно сохранить в БД (и тут как раз и понадобится валидация) или передать другой форме в качестве входных параметров.


Причем тут REST? Я связи не усматриваю.

ВВ>>Исходные данные в удобном формате — это данные в формате, который удобно анализировать. Опять-таки для простоты давайте предпложим, что это ADT, причем данные мы уже волшебным образом получаем в виде:

ВВ>>type MyData = Post | PostComment | Author | ...
VD>В этом описании я вижу кашу из ничем не связанных данных.

Связи действительно мало, так оно понятно, это имитация ХМЛ на основе АДТ.

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

VD>Это здорово! Но опять же смахивает на идею что вражеские самолеты подлетают к нашим границам и падают. Другими словами это все слишком абстрактно. Нужны более глубоко проработанные идеи.

Что конкретно слишком абстрактно? Ты хочешь от меня "спецификацию ДСЛя"?

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

ВВ>>Логика трансформации — это мач.
VD>Одного марча для этого явно не достаточно.

Вполне достаточно. В ХСЛТ один мач по большому счету и есть. Что тебе еще нужно?

VD>К тому же если мы говорим о генерации ХТМЛ-я, то я бы предпочел видеть нечто вроде StringTemplate, движка на который указывал Ziaw или их смеси.


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

VD>Причем логично было бы иметь такую штуку как на сервере, так и на клиенте. И вообще, чем меньше будет разница между сервером и клиентом, тем лучше. Оптимально было бы просто указывать "это выполняем на клиенте" и все.


А если читать внимательно, то можно заметить, что именно это я и предлагаю.

ВВ>>"Шаблон" — это функция (возможно, даже компайл-тайм функция), главной особенностью которой является то, что телом функции является не код на Немерле или чем-то еще

VD>Чем? Опять самолеты...

Предложение до конца не осилил?

ВВ>>- Шаблон всегда возвращает, собственно, XML литерал, причем типизированный (желательно, чтобы по нему тоже можно было мачить по специальному образцу).

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

Идея простая — HTML описывается не через текст, а специальным ДСЛ-ем. По аналогии с Юр-Веб. Этот специальный ДСЛ можно писать только внутри особым образом помеченных функций, которые я называю "шаблон". Данные функции одновременно являются и "конструкторами" в том же смысле, в котором отдельные тэги АДТ. Т.е. совокупность всех функций — это как бы тип данных нашей страницы. По ним можно делать мач по той же самой аналогии, что и с АДТ — "скажи мне каким шаблоном ты был создан".
Причем код для разбора дерева пишется абсолютно одинаково что для клиента, что для сервера.

ВВ>>- Входным параметром (всегда одним) шаблона является продукция ADT (исходных данных)

VD>Во что?

Что "во что"?

ВВ>>- Шаблон может быть перегружен (см. в сторону старого доброго template method),

VD>Может для тебя template method и является старым и добрым, но я вообще не понимаю о чем идет речь.

Тебе не знаком паттерн template method?

VD>И где тут твои АлгТД? Я вижу объекты и что-то вроде стриг-темплэйта.


Это описание конкретного конструктора. АДТ в данном случае будет их совокупность.

ВВ>>Мачить по нему можно как-нибудь так: | >PostTitle>div[@Id] -> [массив всех элементов]

ВВ>>(Еще раз повторюсь: CSS селекторы — в лес )
VD>Мне можешь не повторять. Я их никогда не видел.
VD>Лучше опиши, что означают эти ">PostTitle>div[@Id]" кракозябры? И зачем они вообще нужны?

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

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

VD>Опять какая-та бессмысленная абстракция.

В чем конкретно ты не видишь смысла?

ВВ>>Вся логика описывается отдельно в виде квази-цитат.

VD>Логика чего? К тому же квази-цитаты они как раз для трансформации предназначены.

Вся логика. И как раз она и будет трансформироваться — либо в Немерле, либо в ДжаваСкрипт. О чем я кстати написал ниже, но ты умело поскипал.

ВВ>> Функции автоматически транслируются либо в Немерле, либо в ДжаваСкрипт, если они специальным образом помечаются (или просто требуют доступ к чему-то, что существует только на клиенте). Организация взаимодействия клиент-сервер — через REST/JSON.

VD>Ну, блин, если REST/JSON (что вообще-то понятия разного порядка), то что у нас тут делают АлгТД?

REST/JSON — это наш внутренний протокол, через который будет "внутри", незаметно для пользователя происходить коммуникация между клиентом и сервером.

ВВ>>Да, и конечно *Весь* код лежит в виде "файликов" *.n, компиляция динамическая.

VD>А работать с файликами из нотпэда, без комлита и понятия проекта?

А это тут причем?
Re[28]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 11:39
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну не заставлять же людей писать свои сериализаторы состояние для каждого такого случая? Ведь с РЕПЛом у них таких проблем не будет.


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

ВВ>Т.е. по факту — если убирается динамика и РЕПЛ, то должны предоставляться некие "компенсаторы", позволяющие решать те же задачи.


Согласен. Но никто не отказывается от динамической компиляции. В купе с REST-подобным обменом данным будет очень похожа на то что вы хотите.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 11:46
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Почта какая? vc на рсдн.ру?


Да. В профайле указана.

VD>>Кстати, где можно взять локальную версию MS SQL 2008?


Z>http://www.microsoft.com/sqlserver/2008/ru/ru/express.aspx


Сенкс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 15:14
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Подумай.

ВВ>И чем это "абстрагироваться" отличается от того Wolfhound предлагает?


Тем, что об этом нужно думать.

VD>>Пункт 3 не имеет к первых пунктам ничего общего. Я даже малейшей связи не усматриваю.


ВВ>Связь в том, что это средство для решения типичных задач для веба. Под workflow думай больше в сторону WWF.


WWF точно в задницу.
Правильным решением было реализовать континюэшоны на уровне классов.

VD>>Это что-то вроде REST. На вход мы посылаем иерархию данных запакованных в ХМЛ или Джейсон. На выходе — тоже самое... мы получаем другую иерархию. Эта иерархия является ответом пользователя. Ее можно сохранить в БД (и тут как раз и понадобится валидация) или передать другой форме в качестве входных параметров.


ВВ>Причем тут REST? Я связи не усматриваю.


А причем тут воркфлоу? Говорили о формате представления данных. Тебя унесло к ворфлоу.

ВВ>Связи действительно мало, так оно понятно, это имитация ХМЛ на основе АДТ.


Значит с помощью АлгТД (или ты и правда АТД планируешь использовать?) ты хочешь описывать ХМЛ?

ОК, уже хоть какая-то информация. И как ты это видишь?

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

VD>>Это здорово! Но опять же смахивает на идею что вражеские самолеты подлетают к нашим границам и падают. Другими словами это все слишком абстрактно. Нужны более глубоко проработанные идеи.

ВВ>Что конкретно слишком абстрактно? Ты хочешь от меня "спецификацию ДСЛя"?


Я хочу хотя бы понять что ты понимашь под своими АТД-ами.

Возьми простой пример — пользователи с адресами и опиши (с примерами на псевдокоде) то как ты собираешься поднять эти данные из БД, поместить в свои АТД, опиши эти самые АТД, ну, далее покажи как будет генерироваться ХМЛ и ХТМЛ.

VD>>Одного марча для этого явно не достаточно.


ВВ>Вполне достаточно. В ХСЛТ один мач по большому счету и есть. Что тебе еще нужно?


Вот и покажи как ты с этим матчем на перевес (без if-ов, циклов и всего того что есть в ХМЛТ) будешь все делать. Только конкретно.

VD>>К тому же если мы говорим о генерации ХТМЛ-я, то я бы предпочел видеть нечто вроде StringTemplate, движка на который указывал Ziaw или их смеси.


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


Ты много говришь и ничего конкретного еще не сказал. Рекурсии в StringTemplate выше крыши. Он весь на рекурсии основан. ФВП в шаблонах на фиг не уперлись.

VD>>Причем логично было бы иметь такую штуку как на сервере, так и на клиенте. И вообще, чем меньше будет разница между сервером и клиентом, тем лучше. Оптимально было бы просто указывать "это выполняем на клиенте" и все.


ВВ>А если читать внимательно, то можно заметить, что именно это я и предлагаю.


Ну, я уже говорил по этому поводу. Конкретнее надо быть.

ВВ>>>- Шаблон всегда возвращает, собственно, XML литерал, причем типизированный (желательно, чтобы по нему тоже можно было мачить по специальному образцу).

VD>>Что такое типизированный XML-литерал?

Ответ будет?


ВВ>Идея простая — HTML описывается не через текст, а специальным ДСЛ-ем.


Это идея уровня переворота самолетов на границе. Ты мне примеры покажи.

ВВ> По аналогии с Юр-Веб. Этот специальный ДСЛ можно писать только внутри особым образом помеченных функций, которые я называю "шаблон".


"это" называется квази-цитатой. Это я уже понял. Меня интересует во что эта квази-цитата будет раскываться и почему мы получим что-то там типизированное?

ВВ> Данные функции одновременно являются и "конструкторами" в том же смысле, в котором отдельные тэги АДТ.


А можно использовать не конфликтующую с принятой терминологию?

Что за теги? Кто таки АДТ? Чего конструировать то будем?

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

В случае же описания ХМЛ/ХТМЛ-я мы можем получить только что-то вроде XElement из XLinq-а. Но назвать это типизированным у меня язык не поворачивается. Это конечно уже не текст, но и не типизированные данные.

Типизированными будут объекты. Но объекты должны что-то описывать.

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

ВВ>Причем код для разбора дерева пишется абсолютно одинаково что для клиента, что для сервера.

Код в студию!

ЗЫ

Я тут
Автор: VladD2
Дата: 16.04.10
накидал некоторые мысли. Попытался учесть то, что смог понять из твоих слов (хотя это очень не просто) погляди...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 15:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Подумай.

Вот в чем-то, например, удобен ХМЛ. А ХМЛ представляет собой "объединение" разных типов данных.

ВВ>>И чем это "абстрагироваться" отличается от того Wolfhound предлагает?

VD>Тем, что об этом нужно думать.

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

VD>>>Это что-то вроде REST. На вход мы посылаем иерархию данных запакованных в ХМЛ или Джейсон. На выходе — тоже самое... мы получаем другую иерархию. Эта иерархия является ответом пользователя. Ее можно сохранить в БД (и тут как раз и понадобится валидация) или передать другой форме в качестве входных параметров.

ВВ>>Причем тут REST? Я связи не усматриваю.
VD>А причем тут воркфлоу? Говорили о формате представления данных. Тебя унесло к ворфлоу.

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

ВВ>>Связи действительно мало, так оно понятно, это имитация ХМЛ на основе АДТ.

VD>Значит с помощью АлгТД (или ты и правда АТД планируешь использовать?) ты хочешь описывать ХМЛ?

ADT вроде как сокращение от Algebraic Data Type. А с термином "вариант" в мозгах, к сожалению, прочно укрепились другие ассоциации. ОК, буду называть Discriminated Union. Претензий не будет?
Отвечая на твой вопрос — да, я ищу ближайший аналог.

Простоты ради можем вообще забыть всякие АДТ и АлгТД и всю связанную с ними "хрестоматию" и представить, что у нас есть просто некий литерал для описания объединения.
Попробую объяснить еще раз:

| Post
| Author
| Comment
| ...


Это по сути является "более типизированной" проекцией ХМЛ-я. И точно также как для разбора ХМЛя есть мач, построенный на XPath, здесь есть матч построенный на сопоставление с образцом-конструктором.

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


| PostList{PostBody}
| PostBody(PostTitle,PostMessage,PostComments)
| PostTitle
| PostMessage
| PostComments{PostComment}
| PostComment



Но фактически записываться от будет как класс, в котором есть ф-ции PostList, PostTitle, PostMessage.

Т.е.:
1. Мы получили структуру данных — объединение, которое является практически прямой проекцией БД
2. Мы описываем новую структуру данных, положим так (на псевдокоде):


translation_unit PostSection
{
  template PostTitle(expr : Post) {
     <table>
       <tr>
         <td>{expr.Title}</td>
         <td>{expr.CreateDate}</td>
       </tr>
     </table>
  } 

  template PostBody(expr : Post) { ... }
  ...
}



Как я уже говорил, template — это такой кейворд, который говорит, что внутри метода будет XML литерал.

Эта структура не просто класс, а тоже объединение (в упрощенной форме я его приводил выше). Таким образом, если мы захотим как-то работать со сгенерированным ХТМЛ-ем, мы будет не селекторы писать и не выискать <table> с id таким-то, а работать с ним на более высоком уровне — т.е. на уровне абстракций PostTitle, PostBody и пр.
Т.е. по translation_unit можно также строить мач, причем этот мач может раскрываться как в джава-скрипт, так и в немерле.

ВВ>>Что конкретно слишком абстрактно? Ты хочешь от меня "спецификацию ДСЛя"?

VD>Я хочу хотя бы понять что ты понимашь под своими АТД-ами.

На текущий момент — просто объединение с утиной типизацией. Его требованиям вполне удовлетворяет и немерлевский вариант.

VD>>>Одного марча для этого явно не достаточно.

ВВ>>Вполне достаточно. В ХСЛТ один мач по большому счету и есть. Что тебе еще нужно?
VD>Вот и покажи как ты с этим матчем на перевес (без if-ов, циклов и всего того что есть в ХМЛТ) будешь все делать. Только конкретно.

"всего того что есть в ХМЛТ" — а что еще есть в XSLT? Цмклы и if-ы, собственно, и все. Тем не менее живем же как-то. Циклы выражаются через рекурсию. Против ифоф я ничего не имею, да и они и в мачах есть в виде гвардов.

VD>>>К тому же если мы говорим о генерации ХТМЛ-я, то я бы предпочел видеть нечто вроде StringTemplate, движка на который указывал Ziaw или их смеси.

ВВ>>StringTemplate — это еще один текстовый шаблон "с сиськами". Я же говорю о том, что трансформация должна описываться через рекурсию и ФВП — как это делается в ХСЛТ.
VD>Ты много говришь и ничего конкретного еще не сказал. Рекурсии в StringTemplate выше крыши. Он весь на рекурсии основан. ФВП в шаблонах на фиг не уперлись.

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

ВВ>> По аналогии с Юр-Веб. Этот специальный ДСЛ можно писать только внутри особым образом помеченных функций, которые я называю "шаблон".

VD>"это" называется квази-цитатой. Это я уже понял. Меня интересует во что эта квази-цитата будет раскываться и почему мы получим что-то там типизированное?

Если ты про XML литерал, то раскрываться он будет очевидно в HTML. Типизирован он будет за счет метода-шаблона, который его сгенерировал. Я уже писал — это типизация по принципу "скажи, каким шаблоном ты был создан".
Re[30]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 16:39
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Вот в чем-то, например, удобен ХМЛ.


В чем?

ВВ> А ХМЛ представляет собой "объединение" разных типов данных.


Да ну? А мне так не кажется.

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

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

Это почему каждый? У разных таблицы или разных запросов они разные. В рамках дного запроса одинаковые.

ВВ>Полиморфную логику обработки для них не построить.


А зачем она нужна если данные не полиморфные?

Задача — взять данные из БД и преобразовать их в данные выводимые на страницу (грубо говоря в REST:GET).
Эта задача отлично решается банальными запросами линка.

ВВ>Что ты привязался к этому воркфлоу?


Ты его впихнул. Я тут не причем.

ВВ>ADT вроде как сокращение от Algebraic Data Type.


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

ВВ>А с термином "вариант" в мозгах, к сожалению, прочно укрепились другие ассоциации. ОК, буду называть Discriminated Union. Претензий не будет?


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

ВВ>Попробую объяснить еще раз:


ВВ>
ВВ>| Post
ВВ>| Author
ВВ>| Comment
ВВ>| ...
ВВ>


ВВ>Это по сути является "более типизированной" проекцией ХМЛ-я.


Это по сути является сваливанием в куче вещей которые раньше лежали отдельно.
Смысл в таком варианте есть только если мы планируем хранить все эти типы в рамках одной коллекции.
А мы вроде как не планировали это делать. Так?

ВВ>И точно также как для разбора ХМЛя есть мач, построенный на XPath, здесь есть матч построенный на сопоставление с образцом-конструктором.


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

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


ВВ>
ВВ>| PostList{PostBody}
ВВ>| PostBody(PostTitle,PostMessage,PostComments)
ВВ>| PostTitle
ВВ>| PostMessage
ВВ>| PostComments{PostComment}
ВВ>| PostComment
ВВ>


Хм. Опять варианты используются не по назначению.

Я не вижу в этом никакого смысла.

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

ВВ>Но фактически записываться от будет как класс, в котором есть ф-ции PostList, PostTitle, PostMessage.


ВВ>Т.е.:

ВВ>1. Мы получили структуру данных — объединение, которое является практически прямой проекцией БД

Не-аа. Не является. Мы получили какую-то кашу. В БД есть отдельные списки отдельного типа.

ВВ>2. Мы описываем новую структуру данных, положим так (на псевдокоде):



ВВ>
ВВ>translation_unit PostSection
ВВ>{
ВВ>  template PostTitle(expr : Post) {
ВВ>     <table>
ВВ>       <tr>
ВВ>         <td>{expr.Title}</td>
ВВ>         <td>{expr.CreateDate}</td>
ВВ>       </tr>
ВВ>     </table>
ВВ>  } 

ВВ>  template PostBody(expr : Post) { ... }
ВВ>  ...
ВВ>}
ВВ>



ВВ>Как я уже говорил, template — это такой кейворд, который говорит, что внутри метода будет XML литерал.


Так чем мы описываем ХМЛ-литерал?
Все же остальное будет работать и без суржиковых вариантов. У класса или анонимного типа вполне могут быть такие поля. Я только не понял связи между PostTitle и PostBody. Слишком много за кадром осталось.

ВВ>Эта структура не просто класс, а тоже объединение (в упрощенной форме я его приводил выше). Таким образом, если мы захотим как-то работать со сгенерированным ХТМЛ-ем, мы будет не селекторы писать и не выискать <table> с id таким-то, а работать с ним на более высоком уровне — т.е. на уровне абстракций PostTitle, PostBody и пр.


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

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

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


ВВ>Т.е. по translation_unit можно также строить мач, причем этот мач может раскрываться как в джава-скрипт, так и в немерле.


ОК, но что за тип на выходе у твоих template-ов? И зачем все же тут понадобились варианты?

ВВ>На текущий момент — просто объединение с утиной типизацией. Его требованиям вполне удовлетворяет и немерлевский вариант.


У немерла с утиной типизацией очень плохо. С натяжкой таковой можно назвать методы расширения.

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

ВВ>"всего того что есть в ХМЛТ" — а что еще есть в XSLT? Цмклы и if-ы, собственно, и все.


Ты их "собственно" выкинул. Без них это не язык, а недоразумение.

ВВ>Тем не менее живем же как-то. Циклы выражаются через рекурсию. Против ифоф я ничего не имею, да и они и в мачах есть в виде гвардов.


Т.е. мы позволяем матчи по любым типам данных (как в немерле)? Но в немреле, для удобства работы еще макросы есть. Иначе повесишься.

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


ОК. Как ты это видишь?

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

ВВ>>> По аналогии с Юр-Веб. Этот специальный ДСЛ можно писать только внутри особым образом помеченных функций, которые я называю "шаблон".

VD>>"это" называется квази-цитатой. Это я уже понял. Меня интересует во что эта квази-цитата будет раскываться и почему мы получим что-то там типизированное?

ВВ>Если ты про XML литерал, то раскрываться он будет очевидно в HTML. Типизирован он будет за счет метода-шаблона, который его сгенерировал. Я уже писал — это типизация по принципу "скажи, каким шаблоном ты был создан".


Это ты сейчас ерунду сказал. ХТМЛ — это плоский текст. "Типизированное" — это хотя бы XElement или специализированная структура данных. Скажем для HTML такие структуры создать можно, так как все теги HTML-я специфицированы. Но для ХМЛ-я ты уже таких структур не создашь. Или придется описывать отдельные диалекты ХМЛ-я применяемые в конкретном случае, или пользоваться универсальными решениями вроде XElement, у которых типизация уже не строгая. ХМЛ-ность такие решения еще могут контролировать, но проверить корректность конкретной структуры можно только если будет схема (я, кстати, не уверен, что XLinq умеет схемы на лету проверять).

Итого на повестке дня снова те же вопросы:
1. Зачем в этой схеме АлгТД?
2. Во что будут раскрываться то что чему ты дал префикс "template"?
3. Как это все описывать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 17:22
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В чем?

ВВ>> А ХМЛ представляет собой "объединение" разных типов данных.
VD>Да ну? А мне так не кажется.

А как тебе кажется? Схема это по сути и есть — описание правил объединения.

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

ВВ>>Вот с твоими рекордами — ну честно говоря я просто не знаю что вообще делать
ВВ>>Каждый рекорд — отдельный тип.
VD>Это почему каждый? У разных таблицы или разных запросов они разные. В рамках дного запроса одинаковые.

А запрос всегда делается по одной таблице что ли? Вот и получаешь на выходе n-типов рекордов.

ВВ>>Полиморфную логику обработки для них не построить.

VD>А зачем она нужна если данные не полиморфные?

Как я уже говорил, полиморфные они или нет зависит от тебя самого, от того представления, которое ты для них выберешь. Твой путь это делать свой обработчик для каждого типа рекорда. А в ХТМЛе есть просто, скажем, ссылка (<a href>), абзац, таблица, и они генерируются абсолютно одинаково и от типа рекорда никак не зависят. Таблица в которую выводят пользователи и в которую выводятся роли этих пользователей, или еще что, — это обычно абсолютно одинаковые по логике генерации таблицы. Если хочется DRY — очевидно, надо реюзать эту логику.

ВВ>>ADT вроде как сокращение от Algebraic Data Type.

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

Ну посмотри английскую, она не так категорична.

ВВ>>А с термином "вариант" в мозгах, к сожалению, прочно укрепились другие ассоциации. ОК, буду называть Discriminated Union. Претензий не будет?

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

Да как скажешь. Хотя есть еще такой отличный термин как disjoint join — очень хорошо подходит для того, что я описываю.

ВВ>>Попробую объяснить еще раз:


ВВ>>
ВВ>>| Post
ВВ>>| Author
ВВ>>| Comment
ВВ>>| ...
ВВ>>


ВВ>>Это по сути является "более типизированной" проекцией ХМЛ-я.


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

VD>Смысл в таком варианте есть только если мы планируем хранить все эти типы в рамках одной коллекции.
VD>А мы вроде как не планировали это делать. Так?

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

ВВ>>И точно также как для разбора ХМЛя есть мач, построенный на XPath, здесь есть матч построенный на сопоставление с образцом-конструктором.

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

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

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

ВВ>>
ВВ>>| PostList{PostBody}
ВВ>>| PostBody(PostTitle,PostMessage,PostComments)
ВВ>>| PostTitle
ВВ>>| PostMessage
ВВ>>| PostComments{PostComment}
ВВ>>| PostComment
ВВ>>

VD>Хм. Опять варианты используются не по назначению.

Я уже предложил "аполитичный" термин — объединение. Может, это будет и не вариант — придумаем другую структуру данных. То, что у меня приведено в примере — это высокоуровневое описание результирующего HTML-я. Чтобы мы могли впоследствии не с HTML ДОМом работать, а с нашими более высокоуровневыми абстракциями. Мне казалось, я это вполне понятно объяснил.

VD>Может ты не в курсе, что ПМ (паттерн-матчинг) можно делать по любым объектам? Синтаксис при этом будте не очень красивый, но если мы напишем специальный ДСЛ-чик — аля квази-цитирование, то ПМ будет выглядеть очень цивильно.


А ты наверное не в курсе, что ПМ по *любым* объектам можно написать только в языке с динамической типизацией? Приведи-ка мне пример мач по классам двух разных типов, никак друг с другом не связанных.

ВВ>>Но фактически записываться от будет как класс, в котором есть ф-ции PostList, PostTitle, PostMessage.

ВВ>>Т.е.:
ВВ>>1. Мы получили структуру данных — объединение, которое является практически прямой проекцией БД
VD>Не-аа. Не является. Мы получили какую-то кашу. В БД есть отдельные списки отдельного типа.

Ты эти списки и получил. И у них есть общий тип. В твоей терминологии — это тип "Список". И логика разрабора строится именно на основе типа "Список".

VD>Так чем мы описываем ХМЛ-литерал?


Видимо, макросом.

VD>Все же остальное будет работать и без суржиковых вариантов. У класса или анонимного типа вполне могут быть такие поля. Я только не понял связи между PostTitle и PostBody. Слишком много за кадром осталось.


А что не понял? Это отдельные продукции. Если хочешь — этакая BNF грамматика.

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

ВВ>>Эта структура не просто класс, а тоже объединение (в упрощенной форме я его приводил выше). Таким образом, если мы захотим как-то работать со сгенерированным ХТМЛ-ем, мы будет не селекторы писать и не выискать <table> с id таким-то, а работать с ним на более высоком уровне — т.е. на уровне абстракций PostTitle, PostBody и пр.

VD>Хорошим тоном перед созданием макроса является проработка того что он будет генерировать на практике. Вот в нашем случае тоже нужно так же поступить.

Он будет генерить ХТМЛ, мне кажется, я уже сказал.

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

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

Дыр я так знаю, что много, но я почему-то даже простейшие мысли не могу до тебя донести. Изъясняться я стал непонятно что ли?

ВВ>>Т.е. по translation_unit можно также строить мач, причем этот мач может раскрываться как в джава-скрипт, так и в немерле.

VD>ОК, но что за тип на выходе у твоих template-ов? И зачем все же тут понадобились варианты?

Что за тип на выходе у type Option = Some(x) | None ? Здесь ответ такой же. С той лишь разницей, что в моем случае этот самый "Some" имеет еще и отдельно описанное тело, которое формирует HTML.

ВВ>>На текущий момент — просто объединение с утиной типизацией. Его требованиям вполне удовлетворяет и немерлевский вариант.

VD>У немерла с утиной типизацией очень плохо. С натяжкой таковой можно назвать методы расширения.
VD>Причем тут варианты я до сих пор понять не могу. Складывается впечатление, что они нужны только для МП.

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

ВВ>>"всего того что есть в ХМЛТ" — а что еще есть в XSLT? Цмклы и if-ы, собственно, и все.

VD>Ты их "собственно" выкинул. Без них это не язык, а недоразумение.

Без циклов? Во-первых, если нужно — используй внутри мачей, во-вторых — я не понимаю, в чем проблема все-таки.

ВВ>>Тем не менее живем же как-то. Циклы выражаются через рекурсию. Против ифоф я ничего не имею, да и они и в мачах есть в виде гвардов.

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

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

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

VD>ОК. Как ты это видишь?

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

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


Ну вот собственно как-то так.

ВВ>>Если ты про XML литерал, то раскрываться он будет очевидно в HTML. Типизирован он будет за счет метода-шаблона, который его сгенерировал. Я уже писал — это типизация по принципу "скажи, каким шаблоном ты был создан".

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

Я ведь объяснил как он типизируется, что непонятно? У нас есть ХТМЛ, тупо "плоский текст":

<table>
<tr>
<td>Nemerle on rails</td>
<td>16.04.10</td>
</tr>
</table>

Как он типизирован? Никак.
Но! Мы знаем, что этот ХТМЛ был создан с помощью шаблона PostTitle — и вот PostTitle как раз и является его типом.

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

Здесь также. Мы с этим сниппетом ХТМЛя ничего сделать вообще не можем. Но можем в маче спросить — каким шаблоном ты был создан. Это будет его паттерн. И единственный способ его типизации.
Re[31]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 17:40
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Может ты не в курсе, что ПМ (паттерн-матчинг) можно делать по любым объектам? Синтаксис при этом будте не очень красивый, но если мы напишем специальный ДСЛ-чик — аля квази-цитирование, то ПМ будет выглядеть очень цивильно.


С другой стороны я упустил один весьма важный момент. Вариант или не вариант — все равно получается, что трансформатор должен "знать" те типы, которые сгенерил маппер к БД. При таком подходе вообще можно ПМ и по System.Object написать через type-test паттерн.
А это не катит. Совсем. Так что видимо действительно нужна некая универсальная промежуточная структура.
Re[31]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 17:43
Оценка:
Здравствуйте, VladD2, Вы писали:

Снова я
Попробую суммировать — шаблоны для генерации HTML-я должны отличаться друг от друга не тем с какими "входящими" типами они умеют работать (по каким структурам данных генерировать), а тем, что, собственно, они генерируют. В противном случае получаем гору тупого дублирования.

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

Почему ты мне не сказал, что он нужен для этого, когда предлагал?
Re[32]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 18:06
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>>> А ХМЛ представляет собой "объединение" разных типов данных.

VD>>Да ну? А мне так не кажется.

ВВ>А как тебе кажется?


Мне кажется, что ХМЛ — это отдельный тип (или их набор... как смотреть).

ВВ>Схема это по сути и есть — описание правил объединения.


ХМЛ-схема весьма крива и неудобна. А что такое "описание правил объединения" ты не объясняешь.

ВВ>А запрос всегда делается по одной таблице что ли?


Нет.

ВВ>Вот и получаешь на выходе n-типов рекордов.


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

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

Короче, приведи свой запрос. Поглядим.

ВВ>Как я уже говорил, полиморфные они или нет зависит от тебя самого, от того представления, которое ты для них выберешь. Твой путь это делать свой обработчик для каждого типа рекорда. А в ХТМЛе есть просто, скажем, ссылка (<a href>), абзац, таблица, и они генерируются абсолютно одинаково и от типа рекорда никак не зависят. Таблица в которую выводят пользователи и в которую выводятся роли этих пользователей, или еще что, — это обычно абсолютно одинаковые по логике генерации таблицы. Если хочется DRY — очевидно, надо реюзать эту логику.


Ну, дык ХТМЛ — это или текст, или набор тегов. Он ничего не знает о реально представленных в нем данных.
И что?

ВВ>Я хотел обрабатывать их единообразно.


Ну, так покажи в чем это заключается.

ВВ>А что мы будет с образцом сопоставлять?


Экземпляр любого класса, если нужно.

ВВ>Ты меня поражаешь. Мы не сможем написать мач по твоим рЕкордам просто потому что типичный сценарий генерации должен уметь работать с рЕкордами разного типа. Понимаешь?


Нет. В первую очередь не понимаю кто такие "рЕкордами".

ВВ>Нам пофиг на его тип. Нам нужна утиная типизация.


Зачем? Примеры можно?

ВВ>Вот с точки зрения ХСЛТ-процессора в ХМЛ-е все как раз утино-типизировано, и на задачах генерации UI это весьма удобно.


С точки зрения ХСЛТ в хмле типы вообще не важны. Там преобразуется ХМЛ в ХМЛ (или текст). Там важна структура. Утиной типизации там нет и в помине.

ВВ>Я уже предложил "аполитичный" термин — объединение.


Ты форумом не ошибся?

ВВ>А ты наверное не в курсе, что ПМ по *любым* объектам можно написать только в языке с динамической типизацией? Приведи-ка мне пример мач по классам двух разных типов, никак друг с другом не связанных.


Для особо непонятливых повторяю. В Немерле ПМ можно делать по любым объектам.

VD>>Не-аа. Не является. Мы получили какую-то кашу. В БД есть отдельные списки отдельного типа.


ВВ>Ты эти списки и получил.


Все сразу?

Решительно не понимаю. Код в студию!

ВВ> И у них есть общий тип.


У кого? И зачем?

ВВ> В твоей терминологии — это тип "Список". И логика разрабора строится именно на основе типа "Список".


И что в этот список свалили значения всех таблиц?

VD>>Все же остальное будет работать и без суржиковых вариантов. У класса или анонимного типа вполне могут быть такие поля. Я только не понял связи между PostTitle и PostBody. Слишком много за кадром осталось.


ВВ>А что не понял?


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

ВВ>Это отдельные продукции. Если хочешь — этакая BNF грамматика.


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

ВВ>Блин, а вообще тебя вот не смущает, если б мы писали парсер, и я бы предложил АСТ оформить в виде варианта?


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

ВВ> Нет ведь, наверное, да? Так здесь-то чего тебе не нравится?


Да то же самое. Свалка всего в один вариант. У меня и так есть object. Зафиг его пытаться повторить то?

ВВ>Полная аналогия. АСТ, знаешь ли, тоже можно назвать какой-то кашей из разрозненных типов. Ну ей богу — какая тут связь между "объявлением переменной" и "циклом"?


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

ВВ>Он будет генерить ХТМЛ, мне кажется, я уже сказал.


Мне не надо сказать. Мне надо показать. Пойми, все твои неверные представления развалятся как только ты попытаешься на их основе создать что-то практическое.

VD>>ОК, но что за тип на выходе у твоих template-ов? И зачем все же тут понадобились варианты?


ВВ>Что за тип на выходе у type Option = Some(x) | None ?


А это на каком языке?

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


Покажи, плиз, пример утиной типизации на базе вариантов.

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


1. Это утверждение не соответствует действительности. Немерл поддерживает полиморфный матч — матч по подтипам некоторого базового типа.
2. Если в одном списке есть один тип, а с данными из БД это всегда так, то такой проблемы просто нет.

ВВ>Я вижу разделение на логику трансформации и шаблоны которые используются для формирования собственно разметки. (Это, надеюсь, понятно?)


Да. Но это единственно что понятно.

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


Замечательно. Напиши более-менее полный пример. Так чтобы была ваборка данных из БД, описаны эти таблицы и описан код производящий обработку.

ВВ>Шаблон никакой логики не содержит — это именно шаблон, ХТМЛ сниппет с подстановкой.


Это не совсем верно. Логика представления все же присутсвтует. Для нее нужны все те же управляющие конструции. Как минум: вызов (в том числе рекурсивный), ПМ (полный) и желательно if/else, foreach.

ВВ>Шаблоны можно подменять — хотя бы через наследование и перекрытия (но желательно механизм "по-легче").


Не вопрос. Что до механизма "по-легче", то снова нужны примеры.

ВВ>Ну вот собственно как-то так.


ВВ>Я ведь объяснил как он типизируется, что непонятно?


Ровным счетом ничего. Ты больно крутой ПМ стал. В спецификациях и разговорах используешь полностью абстрактные понятия. Прям как тот муж с самолетами.

ВВ>У нас есть ХТМЛ, тупо "плоский текст":

ВВ><table>
ВВ> <tr>
ВВ> <td>Nemerle on rails</td>
ВВ> <td>16.04.10</td>
ВВ> </tr>
ВВ></table>

ВВ>Как он типизирован? Никак.

ВВ>Но! Мы знаем, что этот ХТМЛ был создан с помощью шаблона PostTitle — и вот PostTitle как раз и является его типом.

Тип текста? Это что-то новенькое. И как в программе эту информацию передать?

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


Кортежи, записи и вхождения вариантов типизируясь конструктором порождают конкретные структуры данных в которых есть поля соответствующие параметрам конструкторов. У тебя же на выходе плоский ктекст.

Вот если ввести некие объекты описывающие этот текст, то будет структурная модель (не не строго-типизированная). Примером такой модели является XLinq. Там есть XElement, XAttribut и т.п. с помощью которых описывается структура ХМЛ-я. Она все равно является слабо-типизированной, так как допускает некорректную (с точки зрения пользователя) структуру и не проверяет тип контента. Но это уже что-то.

Вот я и не могу понять. То может ты предлагаешь создать аналог XLinq для представления ХМЛ? Тогда я могу понять. Можно так же понять более сложный набор типов для описания ХТМЛ-я.

Но как создать заранее известный набор объектов для описания диалектов? Ведь в них могут быть свои теги.

И вообще, это ли ты хочешь создать или и правда хочешь типизированный текст иметь?

ВВ>Здесь также. Мы с этим сниппетом ХТМЛя ничего сделать вообще не можем. Но можем в маче спросить — каким шаблоном ты был создан. Это будет его паттерн. И единственный способ его типизации.


По-моему — это чуешь какая то.

Дальше я обсуждать это не хочу, как чувствую что бестолку теряю время. Если ты приведешь "раскрытый" код простого примера, то я постараюсь его понять. Но абстрактно рассуждать больше не хочу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 18:08
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Почему ты мне не сказал, что он нужен для этого, когда предлагал?


Ты с XLinq работал?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 18:39
Оценка:
Здравствуйте, VladD2, Вы писали:

ВВ>>Полная аналогия. АСТ, знаешь ли, тоже можно назвать какой-то кашей из разрозненных типов. Ну ей богу — какая тут связь между "объявлением переменной" и "циклом"?

VD>Короче, тебе нужно немного разобраться в том где и как используются варианты (АлдТД). У тебя с их пониманием реальная проблема.

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

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

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

О, как. А откуда у тебя "базовые" типы возьмутся? Если есть только никак не связанные "записи". Или матч по object-у делать?

VD>2. Если в одном списке есть один тип, а с данными из БД это всегда так, то такой проблемы просто нет.


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

ВВ>>Я вижу разделение на логику трансформации и шаблоны которые используются для формирования собственно разметки. (Это, надеюсь, понятно?)

VD>Да. Но это единственно что понятно.

Печально, но тут уже ничего не поделаешь. В десятый раз я повторять не буду.
Re[33]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 19:09
Оценка:
Здравствуйте, VladD2, Вы писали:

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

ВВ>>Почему ты мне не сказал, что он нужен для этого, когда предлагал?
VD>Ты с XLinq работал?

Нет, а он чем-то отличается от остальных ДОМ-ов для ХМЛ-я? И чем он поможет?
Re[34]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 19:11
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>А у тебя по ходу реальная проблема с русским языком. Или чем-то еще.


Возможно. Но это к делу не относится.

ВВ>Все элементы АСТ так или иначе должны иметь базовый тип Expr, без этого ты AST не напишешь. А сколько у тебя будет подтипов — вопрос десятый.


Вот здесь находятся все элементы AST немерла.

Все это элементы AST. Посчитай сколько там вариантов и классов.

ВВ>О, как. А откуда у тебя "базовые" типы возьмутся? Если есть только никак не связанные "записи". Или матч по object-у делать?


А зачем он? АСТ типов не надо хранить вместе с АСТ выражений. АСТ параметров не надо хранить вместе с АСТ членов классов и т.п.

VD>>2. Если в одном списке есть один тип, а с данными из БД это всегда так, то такой проблемы просто нет.


ВВ>В случае хотя бы более или менее нормализованной БД это практически всегда не так.


Все с точностью наоборот.

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


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


ВВ>>>Я вижу разделение на логику трансформации и шаблоны которые используются для формирования собственно разметки. (Это, надеюсь, понятно?)

VD>>Да. Но это единственно что понятно.

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


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

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

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

Точно так же нам нет нужды хранить в одном списке покупателей и заказы. По этому мы их не помещаем в один вариант.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 19:27
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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

ВВ>>>>Я вижу разделение на логику трансформации и шаблоны которые используются для формирования собственно разметки. (Это, надеюсь, понятно?)

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

Я предложил уже эту терминологию оставить в сторону, если ты считаешь, что она тут не подходит. Речь идет именно об объединении разных структур данных, какое я и получаю в XML-e, веришь ты или нет. Причем тот факт, что схема внешняя очень даже удобен, т.к. ХМЛ типизирован ровно тогда когда это нужно, и не более того.

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

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

Ты же хочешь, чтобы код на Немерле транслировался в ДжаваСкрипт? А как он по-твоему будет работать с ДОМом?

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

Теперь смотрим на мое предложение рассматривать шаблоны для генерации как этакие типы, которые можно анализировать.
Re[34]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 19:40
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Нет, а он чем-то отличается от остальных ДОМ-ов для ХМЛ-я? И чем он поможет?


Да. Очень сильно. Он в функциональном стиле написан.

Погляди его. А в понедельник ответь не это ли ты имеешь в виду под "типизированным".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[36]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.04.10 20:01
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Я говорил — я ищу аналог ХМЛю. Точка.


Так ХМЛ — это совсем не тоже самое что типизированные данные модели. Погляди Linq 2 XML. Возможно — это то что тебе нужно.

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


ХМЛ без поддержки схемы можно описать очень простым вариантом. Примерно таким:
varinat Xml
{
  | Elem { prefix : string; name : string; content : list[Xml]; }
  | Attr { prefix : string; name : string; value   : string; }
  | Text { value   : string; }
}


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

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

Опять же ты понимаешь что структура ХТМЛ и структура данных отображаемая в нем — это не одно и тоже?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 16.04.10 22:10
Оценка:
Здравствуйте, VladD2, Вы писали:

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

ВВ>>Я говорил — я ищу аналог ХМЛю. Точка.

VD>Так ХМЛ — это совсем не тоже самое что типизированные данные модели. Погляди Linq 2 XML. Возможно — это то что тебе нужно.


ОК, посмотрю.
И, кстати, я не про данные модели говорю.

VD>ХМЛ без поддержки схемы можно описать очень простым вариантом. Примерно таким:

VD>
VD>varinat Xml
VD>{
VD>  | Elem { prefix : string; name : string; content : list[Xml]; }
VD>  | Attr { prefix : string; name : string; value   : string; }
VD>  | Text { value   : string; }
VD>}
VD>


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

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

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

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

Например, я в ДжаваСкрипте для того, чтобы добавить меню-айтем добавлю в ХМЛ-дерево тэг MenuItem с соответствующими атрибутами, а не таблицу с вложенной таблицей и пр.

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

Если хочешь — задача в том, чтобы ХТМЛ перестал быть текстом на сервере.
Re[34]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.10 19:30
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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

ВВ>>>Почему ты мне не сказал, что он нужен для этого, когда предлагал?
VD>>Ты с XLinq работал?

ВВ>Нет, а он чем-то отличается от остальных ДОМ-ов для ХМЛ-я? И чем он поможет?


Ну, что? Посмотрел?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 19.04.10 19:44
Оценка:
Здравствуйте, VladD2, Вы писали:

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

ВВ>>>>Почему ты мне не сказал, что он нужен для этого, когда предлагал?
VD>>>Ты с XLinq работал?
ВВ>>Нет, а он чем-то отличается от остальных ДОМ-ов для ХМЛ-я? И чем он поможет?
VD>Ну, что? Посмотрел?

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

Т.е. если к примеру у тебя задача сгенерировать иерархическое меню, то у тебя могут быть типы Menu, MenuItem и так далее. Согласись, что когда возникает задача модификации меню, куда удобнее не перерывать гору ХТМЛ-я, а работать с конкретной объектной моделью. Собственно, на стороне сервера так обычно и происходит. Но на клиенте есть лишь универсальный HTML DOM и любые модификации предполагают работу с этим DOM-ом.

Какие преимущества давало, например, вытаскивание логики генерации интерфейса на клиента. Сам по себе подход, мягко говоря, неуниверсальный, имеющий много недостатков, но благодаря нему клиентский скрипт мог работать именно с "типизированной" версией UI — т.е. не вложенные таблицы перебирать, а оперировать с MenuItem, MenuFolder и так далее.

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

Я предлагал нечто подобное, но без XML и на сервере. Хочешь сгенерировать HTML? Изволь описать некое дерево типов, через которые ты сможешь с ним работать. И каждому отдельному типу в этой иерархии будет соответствовать свой шаблон, используемый для его превращения в HTML.
Re[36]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.10 19:59
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

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


Ну, и как ты это себе видешь? Ведь для проблемно-ориентированной нужно ведь специализированные типы описывать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 19.04.10 20:23
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Ну, и как ты это себе видешь? Ведь для проблемно-ориентированной нужно ведь специализированные типы описывать.

Ну так и вижу — описывать специализированные типы. На самом деле их зачастую так или иначе приходится описывать. Если интерфейс мало-мальски сложный, то без какой-то промежуточной структуры данных никуда.
Я представляю, что, скажем, для того же меню есть некая иерархия типов — вполне можно сделать так, что она будет описываться очень лаконично. При этом каждому типу в данной иерархии соответствует свой шаблон, отвечающий за генерацию HTML. По большому счету берем XML/XSLT и портируем в Си-подобный синтаксис
Re[38]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.04.10 20:36
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>По большому счету берем XML/XSLT и портируем в Си-подобный синтаксис


Я тебе уже сказал, что XML описывается за 3 минуты. К тому уже есть XLinq.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: Nemerle on rails
От: Воронков Василий Россия  
Дата: 19.04.10 21:01
Оценка:
Здравствуйте, VladD2, Вы писали:

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


ВВ>>По большому счету берем XML/XSLT и портируем в Си-подобный синтаксис


VD>Я тебе уже сказал, что XML описывается за 3 минуты. К тому уже есть XLinq.


Что-то ты тормозишь, мне кажется. Нет задачи XML в Немерле "портировать". Есть задача описывать то же, что и в ХМЛ, но другими средствами. Например, есть XML:


<Menu>
  <MenuItem Text="Parent">
     <MenuItem Text="Child"/>
  </MenuItem>
</Menu>



И код на Немерле:


variant Menu
{
  | MenuItem { Text: string; Child: Menu; }
}



Код на XSLT:


<xsl:for-each select="/MenuItem">
   <xsl:call-template name="RenderMenu" />
   ...
</xsl:for-each>



На Немерле:


def renderMenu(menu) {
  | MenuItem(t, c) -> renderText(text) + renderMenu(c)
}
Re: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.05.10 18:37
Оценка:
Здравствуйте, Ziaw, Вы писали:

Как продвигаются дела?

Есть ли сложности?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nemerle on rails
От: Ziaw Россия  
Дата: 13.05.10 02:46
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как продвигаются дела?


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

VD>Есть ли сложности?


МС миграций закончен, думаю над следующим МС. Для него мне нужно уметь:

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

Пока не знаю что из этого вызовет большие сложности, если заранее подскажешь будет хорошо.
Re[3]: Nemerle on rails
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.05.10 17:47
Оценка:
Здравствуйте, Ziaw, Вы писали:

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

    Это возможно.

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


    Вопрос только в том на основании чего их генерировать.

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

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


    Проблемы могут возникнуть если пытаться генерировать типы по выражениям получаемым из тел методов. Дело в том, что в IDE тела методов обрабатываются в отложенном режиме и по многу раз (каждое редактирование может заставить обработать один или все методы).

    Так что выбирая дизайн нужно постараться сделать так, чтобы данные (модель) по которым будет генерироваться кода были доступны без заглядывания внутрь тел методов. Например, в виде атрибутов или в виде типов. Ну, типа описываешь декларативно некий тип, а уже по нему генерируется модель, контроллер и т.п.
  • Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[2]: Еще один интересный проект
    От: Ziaw Россия  
    Дата: 16.05.10 13:45
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Тем кто еще не видел очень советую посмотреть на этот проект: http://www.impredicative.com/ur/


    Вот это, кстати, мне больше понравилось http://groups.inf.ed.ac.uk/links/examples/
    Синтаксис близок к немерлу.

    Но сгенеренный jscript похож на обфусцированный.
    Re[3]: Еще один интересный проект
    От: WolfHound  
    Дата: 16.05.10 16:25
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

    Z>Вот это, кстати, мне больше понравилось http://groups.inf.ed.ac.uk/links/examples/

    А мне совсем не нравится.

    Z>Синтаксис близок к немерлу.

    Синтаксис дело десятое.
    Главно что что urweb декларативный, а этот императивный.

    Z>Но сгенеренный jscript похож на обфусцированный.

    Это вообще дело десятое.
    Тут чем быстрее и компактнее тем лучше. Читаемость генеренных жабаскриптов никого не интересует также как никого не интересует читаемость машинных кодов.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[4]: Еще один интересный проект
    От: Ziaw Россия  
    Дата: 17.05.10 05:03
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    Z>>Синтаксис близок к немерлу.

    WH>Синтаксис дело десятое.
    WH>Главно что что urweb декларативный, а этот императивный.

    Гм... Я бы сказал, что он чуть менее чист функционально чем хаскель. Не декларативным он от этого не становится. Всю логику там можно реализовать на замыканиях и continuations(продолжениях?). Где там императив-то? Неужели for? Это насквозь декларативный сахар для list comprehension.

    Хотя возможность включения императива вполне в духе Nemerle и должна бы приветствоваться.

    Z>>Но сгенеренный jscript похож на обфусцированный.

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

    В том то и дело, что он не компактен как минимум, потому и быстрым быть не может, т.к. генерит большой кусок рантайма внутрь страницы, что убивает кеширование. Впрочем это не суть важно.
    Re[5]: Еще один интересный проект
    От: WolfHound  
    Дата: 17.05.10 09:51
    Оценка:
    Здравствуйте, Ziaw, Вы писали:

    Z>Гм... Я бы сказал, что он чуть менее чист функционально чем хаскель. Не декларативным он от этого не становится. Всю логику там можно реализовать на замыканиях и continuations(продолжениях?). Где там императив-то? Неужели for? Это насквозь декларативный сахар для list comprehension.

    Это не мешает ему быть по сути императивным
    Сравни
    http://groups.inf.ed.ac.uk/links/examples/draggable.links
    http://groups.inf.ed.ac.uk/links/examplessrc/draggable.links
    и
    http://www.impredicative.com/ur/more/dragList.html

    Вариант links машина состояний
    fun waiting(id) client {
     receive {
      case MouseDown(elem)  ->
       if (isElementNode(elem) && (parentNode(elem) == getNodeById(id)))
        dragging(id, elem)
       else
        waiting(id)
      case MouseUp          -> waiting(id)
      case MouseOut(toElem) -> waiting(id)
     }
    }
    
    fun dragging(id, elem) client {
     receive {
      case MouseUp          -> waiting(id)
      case MouseDown(elem)  ->
       if (isElementNode(elem) && (parentNode(elem) == getNodeById(id)))
        dragging(id, elem)
       else
        waiting(id)
      case MouseOut(toElem) ->
       if (isElementNode(toElem) && (parentNode(toElem) == getNodeById(id))) {
        swapNodes(elem, toElem);
        dragging(id, elem)
       } else dragging(id, elem)
     }
    }

    В варианте ur/web нет ничего и близко похожего.

    Причем ur/web можно сделать еще лучше
    fun draggableList title items =
        itemSources <- List.mapM source items;
        draggingItem <- source None;
        return <xml>
          <h2>Great {[title]}</h2>
          <ul onmouseout={set draggingItem None}>
                    <li each itemSource in itemSources
                            onmousedown={set draggingItem (Some itemSource)}
                            onmouseup={set draggingItem None}
                            onmouseover={
                                                        di <- get draggingItem;
                                                        case di of
                                                            | None => return ()
                                                            | Some di =>
                                                                original <- get di;
                                                                movedOver <- get itemSource;
                                                                set di movedOver;
                                                                set itemSource original;
                                                                set draggingItem (Some itemSource)
                                                    }
                        >
                        <dyn item=itemSource>{[item]}</dyn>
                 </li>
          </ul>
        </xml>

    Принципиальная разница в том что links манипулирует уже готовыми кусками страници причем весьма императивно.
    ur/web использует связку source/dyn которая работает исключительно с исходными данными.
    При изменении source все зависимые от него dyn перестраиваются. Причем одному dyn'у никто не мешает быть зависимым от нескольких source.

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

    Нет. Не должна.

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

    Это утверждение более чем спорно.

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

    То что они вообще кладут скрипты внутрь страници это плохо.
    Все скрипты должны идти отдельным файлом. Причем имя файла нужно генерировать на основе например sha1 от его содержимого и выставлять вечное кеширование.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[2]: Nemerle on rails
    От: Ziaw Россия  
    Дата: 17.05.10 16:38
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Как продвигаются дела?


    Миграции работают. Критика приветствуется.
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.