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

Первая часть уже готова, хотим конструктивной критики.

https://docs.google.com/document/d/1EJn3wuKs69J1CiEuEvctrCjtA41FeL2ah528o9k0NDg/pub

В планах опубликовать на рсдн, хабре, реддите, HackerNews.

Было бы интересно прочесть о генерируемом JS и возможностях отладки данного Nemerle кода.

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

А>Было бы интересно прочесть о генерируемом JS и возможностях отладки данного Nemerle кода.

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

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

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

1. Простейший пример не расцвечен.
2. <# #> лучше заменить на, что то другое, что расцвечивает текст. Отсутствие подсветки в хтмл это минус
3. для списка List[Task] если возможно добавить перекрытие метода Add с параметрами конструктора Task

     _db.Add(Task("Write article", false, "high"));
     _db.Add(Task("Fix website bugs", false, "high"));
     _db.Add(Task("Add new functionality", false, "low"));

заменить

     _db.Add("Write article", false, "high");
     _db.Add("Fix website bugs", false, "high");
     _db.Add("Add new functionality", false, "low");

4.
public Save(tasks : List[Task]) : string
не понятно куда идет возвращаемая строка.

5. Не ясно где находятся переменные на клиенте или на сервере или автоосериализуются между ними.
mutable _tasks = List.[Task]();
mutable _todoName = "New task";
mutable _todoPriority = "high";

6. Сохраняется на сервере в моем представлении это или в БД или в файле.


Молодцы! не думал, что такое скажу. Красиво сделано.

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

А>1. Простейший пример не расцвечен.
Подсветку сегодня поправим, у меня просто на работе тема в студии другая, поэтому не смог сразу сделать.

А>2. <# #> лучше заменить на, что то другое, что расцвечивает текст. Отсутствие подсветки в хтмл это минус
<# #> должен подкрашивать, тут вопрос в макросе Html. Я тут со всеми делами забыл про эту проблему, надо будет с Владом посоветоваться.

А>3. для списка List[Task] если возможно добавить перекрытие метода Add с параметрами конструктора Task
А каким образом? Разве что макрос какой замутить, но это ведь обычный серверный код. Зачем его так коверкать?

А>4.
А> public Save(tasks : List[Task]) : string
А>не понятно куда идет возвращаемая строка.
Тут наверное надо сделать сноску. Дело в том, что серверные методы должны возвращать какое-то значение, даже если логически его может не быть.
Но вообще можно генерировать null для void методов.

А>5. Не ясно где находятся переменные на клиенте или на сервере или автоосериализуются между ними.
А>mutable _tasks = List.[Task]();
А> mutable _todoName = "New task";
А> mutable _todoPriority = "high";
Все переменные на клиенте. Какой-либо синхронизации с сервером нет. Все данные передаются явно через вызовы методов, в которых как раз происходит автоматическая сериализация.

А>6. Сохраняется на сервере в моем представлении это или в БД или в файле.
Ну, static List[T] это в некотором плане in-memory DB

А>Молодцы! не думал, что такое скажу. Красиво сделано.

Спасибо за конструктивную критику!

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

6. Не всегда работает бродкаст
примерно в 80% случаях нормально
Как проверял, открываю 2 вкладки и сталя/убираю галочки
иногда на другой странице не происходит обновление
Хром 35

7.

 // <# #> - аналог C# строк вида @””, но позволяет писать обычные кавычки
 // и поддерживает рекурсию.

не совсем ясно о какой рекурсии идет речь

8.

<tr $foreach(task in _tasks.OrderBy(t => t.Priority))>

Не объяснено различие и почему сделано так, а не

$foreach(task in _tasks.OrderBy(t => t.Priority)) 
{       
<tr>

}

9. SignalR собираетесь убрать? Почему был выбран именно он.

А>6. Не всегда работает бродкаст
А>примерно в 80% случаях нормально
А>...
Спасибо, не заметили бага. Запрос от сервера приходит всегда, но данные иногда обновляется некорректно. Позже посмотрю в чём причина.

А>7.
А>

А> // <# #> - аналог C# строк вида @””, но позволяет писать обычные кавычки
А> // и поддерживает рекурсию.
А>

А>не совсем ясно о какой рекурсии идет речь

https://github.com/rsdn/nemerle/wiki/Lexical-structure-(ref)#Recursive_string_literals__string

А>8.
А>Не объяснено различие и почему сделано так, а не

А>

А>$foreach(task in _tasks.OrderBy(t => t.Priority)) 
А>{       
А>...
А>

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

А>9. SignalR собираетесь убрать? Почему был выбран именно он.
Потому что не хотим городить свою систему push нотификаций. А SignalR по сути уже является стандартом в этой области для ASP.NET.

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

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

Извините, но объяснений ПОЧЕМУ у вас как раз и нет! Вся схема статьи — "наш фрэймворк делает то-то и то-то, а вот и пример!". Как же я пойму, что это круто, если нет ни единого сравнения с существующими решениями?
Опустим всякие RoR'ы, хотя и там есть чем похвалиться... Например, ASP.NET — чем решение на НемерлеВебЪ будет короче/эффективнее/быстрее/гибче/вписантьнужное? Будет ли разработка в НемерлеВеб удобнее, чем ASP в студии? (напомню — там есть подсветка как HTML, так и C#) Можно ли как-то варьировать выход? Скажем, на ASP я могу заточиться на HTML 3.2 и отсутствие JS (ну а почему бы и нет?). Почему вообще рассматривается подход "Исходник на Немерле + вкрапления HTML-я"? Ведь не секрет, что дизайнеры не сидят в студиях, а вузивугно ваяют шаблоны, в которые потом уже вставляют код. Т.е. приоритет — удобство дизайнера и только потом вступает в игру прогер.
В общем, я б пока не рекомендовал публиковать статью — слишком много вопросов для заголовка, претендующего всё объяснить.

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

B>Извините, но объяснений ПОЧЕМУ у вас как раз и нет! Вся схема статьи — "наш фрэймворк делает то-то и то-то, а вот и пример!". Как же я пойму, что это круто, если нет ни единого сравнения с существующими решениями?
B>Опустим всякие RoR'ы, хотя и там есть чем похвалиться... Например, ASP.NET — чем решение на НемерлеВебЪ будет короче/эффективнее/быстрее/гибче/вписантьнужное? Будет ли разработка в НемерлеВеб удобнее, чем ASP в студии? (напомню — там есть подсветка как HTML, так и C#) Можно ли как-то варьировать выход? Скажем, на ASP я могу заточиться на HTML 3.2 и отсутствие JS (ну а почему бы и нет?). Почему вообще рассматривается подход "Исходник на Немерле + вкрапления HTML-я"? Ведь не секрет, что дизайнеры не сидят в студиях, а вузивугно ваяют шаблоны, в которые потом уже вставляют код. Т.е. приоритет — удобство дизайнера и только потом вступает в игру прогер.
B>В общем, я б пока не рекомендовал публиковать статью — слишком много вопросов для заголовка, претендующего всё объяснить.

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

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

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

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

B>Извините, но объяснений ПОЧЕМУ у вас как раз и нет! Вся схема статьи — "наш фрэймворк делает то-то и то-то, а вот и пример!". Как же я пойму, что это круто, если нет ни единого сравнения с существующими решениями?
Сравнение с другими решениями это не лучший способ познакомить с возможностями, имхо.

B>Опустим всякие RoR'ы, хотя и там есть чем похвалиться... Например, ASP.NET — чем решение на НемерлеВебЪ будет короче/эффективнее/быстрее/гибче/вписантьнужное?
NemerleWeb работает поверх ASP.NET MVC, он не занимается генерацией статических страниц. NemerleWeb — это чисто Single Page Application фреймворк, который умеет удобно общаться с сервером.

B>Будет ли разработка в НемерлеВеб удобнее, чем ASP в студии? (напомню — там есть подсветка как HTML, так и C#)
Как я уже написал, эти фреймворки не конкурируют друг с другом, а дополняют.

B>Можно ли как-то варьировать выход? Скажем, на ASP я могу заточиться на HTML 3.2 и отсутствие JS (ну а почему бы и нет?).
Нельзя, у нас полная динамика. Там где нужен опциональный JS от нашего фреймворка будет мало толку. Как и впрочем от AngularJS, Knockout, Meteor и остальных.

B>Почему вообще рассматривается подход "Исходник на Немерле + вкрапления HTML-я"?
Потому что такой подход позволяет удобно декомпозировать как логику, так и представление. А если очень хочется использовать разметку от дизайнера, то её можно почти 1 в 1 вставить в строку и разбавить директивами.
Без данных шаблон будет бесполезен.

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

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

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

B>>Извините, но объяснений ПОЧЕМУ у вас как раз и нет! Вся схема статьи — "наш фрэймворк делает то-то и то-то, а вот и пример!". Как же я пойму, что это круто, если нет ни единого сравнения с существующими решениями?
I>Сравнение с другими решениями это не лучший способ познакомить с возможностями, имхо.

Осмелюсь огорчить, но ваше "имхо" смотрит на проблему совсем неправильно. Поясню: не бывает просто "крутых фрэймворков" — крутизна — понятие ОТНОСИТЕЛЬНОЕ. Вася круче Пети, потому что у Васи BMW X7, а у Пети — "Калина".
В вашем случае у вас есть просто "Калина" (ну ладно, Daewoo Matiz ) и вы его называете "крутым" — по отношению к чему? К CGI-скриптам на Perl? И опять же, речь пока что не о возможностях конкретно вашего фрэймворка, а о том, чем он круче существующих решений! Думаете, другие фрэймворки делали менее амбициозные люди? У них тоже есть "крутые фичи", может быть даже намного круче Немерли — как тут судить? Только сравнением! Причём всесторонним: по количеству LOC, по гибкости решения, по удобству для всех членов команды, по реюзабельности и т.п. Просто пример "ToDo" показывает ваше решение, а может на Django оно вообще займёт 10 строк!


I>NemerleWeb работает поверх ASP.NET MVC, он не занимается генерацией статических страниц. NemerleWeb — это чисто Single Page Application фреймворк, который умеет удобно общаться с сервером.
Про ASP — просто пример, мне всё равно кто поверх кого работает. Возьмите хоть дюжину PHP-движков — чем ОНИ хуже НемерлеВеб? Там тоже язык+встроенный HTML, да ещё куча вкусняшек дописана. Не получится ли так, что php-сайт будет десятикратно проще и быстрее в разработке?


B>>Будет ли разработка в НемерлеВеб удобнее, чем ASP в студии? (напомню — там есть подсветка как HTML, так и C#)
I>Как я уже написал, эти фреймворки не конкурируют друг с другом, а дополняют.

Дополняют — это если бы я взял готовое ASP-решение и в три клика прикрутил к нему Немерле + валидацию, например. Да и не видно по вашему введению, что это вообще что-либо дополняет! "Вот есть НемерлеВеб, а вот так он делает вот это" — общий смысл статьи.

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

А когда шаблон придётся улучшать — опять вырезаем из исходника Немерли, правим, вставляем обратно?
Просто подумайте, что чаще меняется — код взаимодействия с БД или дизайн страницы? А что легче править — немерловый исходник из студии или HTML-вкрапления, разбавленные к тому же несовместимыми foreach'ами внутри тегов?
Не думайте о мире с позиции "все в мире программисты-немерлисты": дизайнеру плевать на код, ему нужен визуальный редактор + удобный доступ к исходникам. Пришла директива поправить таблицу — кликнул на шаблоне, увидел готовый результат (WYSIWYG), поменял цвета и даже не вникая в теги сохранил шаблон — всё, больше никаких движений вы от дизайнера не имеете права требовать! Поэтому меня и смутили эти вставки "дизайнерского креатива" внутри немерловых скобочек — это в корне неправильно.


I>Для этого и выложил сюда, чтобы определить что людям непонятно и как можно сделать статью доступнее для всех

Вообще ничего непонятно, если откровенно. Да, вижу решение задачи ToDo — и что? Почему я должен бросать, скажем, RoR? На сколько повысится моя эффективность с NemerleWeb? А что мне делать с дизайнером, у которого стоит 27" iMac (представь, да!) и он слышать ничего не хочет о странных файлах с именем *.n? Даже в сравнении с ASP.NET я всё ещё не улавливаю счастья переписываения этого на НемерлеВеб.

Тут, видимо, глобальное заблуждение: у вас есть Немерле, вы его хорошо знаете и вот родился проект, позволяющий минимумом телодвижений ещё и веб-страницы выдавать! На самом же деле сайт — это прежде всего ВИД и только потом — бэкграунд код, позволяющий что-то там красиво доставать из базы. Представьте, что вам заказали сайт гуманоиды — они умеют писать по-русски, сохранять файлы и кое-как управляться с тегами HTML. Вы одноразово написали сайт, а дальше контент, новости, красявки и градиентики делают люди, которые слово "Немерле" даже выговорить не в состоянии! ЧТО вы им дадите как результат? Валежник *.n файлов и инструкцию "как править теги внутри <##>"? А это и есть состояние любой веб-студии! Смешно получилось.

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

B>...

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

Получился вопрос в стиле — "чем ASP.NET MVC лучше C#". Я, честно говоря, не знаю как на это отвечать

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

I>Ты извини, но ты либо очень далёк от темы и зашёл просто поболтать, либо ты даже не удосужился статью прочитать.

I>Получился вопрос в стиле — "чем ASP.NET MVC лучше C#". Я, честно говоря, не знаю как на это отвечать

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

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

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

I>Ты извини, но ты либо очень далёк от темы и зашёл просто поболтать, либо ты даже не удосужился статью прочитать.

Да ради бога! Считаешь себя самым умным и что ты написал достойную статью — усираться переубеждать не буду, это тебе граблями получать. Просто ты спросил совета у посторонних людей и я тебе объяснил, что ты НИЧЕГО не объяснил своей статьёй. А сейчас ты тупо хамишь, вместо элементарного приведения аргументов. Если считаешь, что я не прав — цитируй, приводи аргументы. Нет аргументов — не пори чушь, за которую потом будет стыдно.

I>Получился вопрос в стиле — "чем ASP.NET MVC лучше C#".

Я эти еврейские методы спора уже давно просёк, не старайся. Приведи мне мою цитату сравнения "чем ASP.NET MVC лучше C#" или признай себя обиженным треплом.

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

WH>Проблема в том, что они с мамутом думают, что это очередной шаблонизатор.

Вольф, проблема ещё хуже и запущщеннее! Кое-кто думает, что обладает достаточным слогом и знаниями, чтобы объяснить "что такое НемерлеВеб". На данный момент я не вижу даже 1% пояснений, всё сводится к скучным примерам, показывающим лишь как Немерле справляется с какой-то частной задачей. Если автор НЕ МОЖЕТ объяснить что он создал, кто ж тогда ПОЙМЁТ что он создал?!

WH>И хрен их убедишь, что они нихрена не поняли.

Не пеняй с больной головы на здоровую. Если ты пытаешься языком жестов племени Зулу объяснить работу коллайдера, ты не добьёшься успеха. Так какое право ты имеешь винить общество, не понимающее местных "гениев макросов"??

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

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

B>>Извините, но объяснений ПОЧЕМУ у вас как раз и нет! Вся схема статьи — "наш фрэймворк делает то-то и то-то, а
вот и пример!". Как же я пойму, что это круто, если нет ни единого сравнения с существующими решениями?
I>Сравнение с другими решениями это не лучший способ познакомить с возможностями, имхо.

Наоборот. Из твоей статьи ровно ничего не ясно.

http://dev.sencha.com/deploy/ext-4.0.1/examples/feed-viewer/feed-viewer.html

Вот возможности Ext.js, а чего у тебя — совершенно не ясно. Ну или вот — в ангуляре для твоих примеров мне нужен один единтсвенный html, как то так

I>NemerleWeb работает поверх ASP.NET MVC, он не занимается генерацией статических страниц. NemerleWeb — это чисто Single Page Application фреймворк, который умеет удобно общаться с сервером.

Чем это лучше Angular, Knockout, Ext.js ?

Как мне добавить поддержку ну скажем тач-эвентов ?

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

B>К слову, это уже не первая попытка объяснить и все они сводятся к "вы все хреновые читатели, ничего не понимаете" — тебе не кажется, что бывают не только "глупые читатели", но и косноязычные объяснятели?
Бывают. Но тут не тот случай. Ибо есть куча людей, которые всё поняли сразу.
Глядя на вас с мамутом я не вижу, что вы даже пытаетесь понять, что конкретно вы не понимаете.

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

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

B>А когда шаблон придётся улучшать — опять вырезаем из исходника Немерли, правим, вставляем обратно?

Т.е. все претензии к формату шаблонизатора ?
Вместо:

<tr $when(x)>
 ..
</tr>

Вы хотите видеть:

@when(...)
{
  <tr>
 ..
  </tr>
}

Или

<tr data-ng-when="...">
 ..
</tr>

Это все возможно, но сначала стоит это обсудить.

Хочу только заметить, что это не единственный шаблонизатор где нет чистого 'HTML': Haml, Kara, WebSharper и т.д.

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

I>>Ты извини, но ты либо очень далёк от темы и зашёл просто поболтать, либо ты даже не удосужился статью прочитать.
B>Да ради бога! Считаешь себя самым умным и что ты написал достойную статью — усираться переубеждать не буду, это тебе граблями получать. Просто ты спросил совета у посторонних людей и я тебе объяснил, что ты НИЧЕГО не объяснил своей статьёй. А сейчас ты тупо хамишь, вместо элементарного приведения аргументов. Если считаешь, что я не прав — цитируй, приводи аргументы. Нет аргументов — не пори чушь, за которую потом будет стыдно.

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

I>>Получился вопрос в стиле — "чем ASP.NET MVC лучше C#".
B>Я эти еврейские методы спора уже давно просёк, не старайся. Приведи мне мою цитату сравнения "чем ASP.NET MVC лучше C#" или признай себя обиженным треплом.

B>... Про ASP — просто пример, мне всё равно кто поверх кого работает. Возьмите хоть дюжину PHP-движков — чем ОНИ хуже НемерлеВеб? Там тоже язык+встроенный HTML, да ещё куча вкусняшек дописана. Не получится ли так, что php-сайт будет десятикратно проще и быстрее в разработке? ...

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

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

B>>>Извините, но объяснений ПОЧЕМУ у вас как раз и нет! Вся схема статьи — "наш фрэймворк делает то-то и то-то, а
I>вот и пример!". Как же я пойму, что это круто, если нет ни единого сравнения с существующими решениями?
I>>Сравнение с другими решениями это не лучший способ познакомить с возможностями, имхо.
I>Наоборот. Из твоей статьи ровно ничего не ясно.
I>http://dev.sencha.com/deploy/ext-4.0.1/examples/feed-viewer/feed-viewer.html
Так тут ведь нет никаких сравнений с другими фреймворками...

I>Вот возможности Ext.js, а чего у тебя — совершенно не ясно.
Ты ведь привёл целый сайт, а у нас статья на 5 минут чтения. Конечно на сайте будет более подробно расписано. У нас на сайте тоже побольше информации, хотя и он далёк от того, что хотелось бы видеть.

I>Ну или вот — в ангуляре для твоих примеров мне нужен один единтсвенный html, как то так
Да, такого механизма как в ангуляре у нас — данные должны быть объявлены явно. По-моему так правильнее, но это мой, чисто субъективный взгляд.

I>>NemerleWeb работает поверх ASP.NET MVC, он не занимается генерацией статических страниц. NemerleWeb — это чисто Single Page Application фреймворк, который умеет удобно общаться с сервером.
I>Чем это лучше Angular, Knockout, Ext.js ?
Надо наверное отдельную статью написать, где будут сравнения. Умудриться всё запихать в три страницы просто нереально.

I>Как мне добавить поддержку ну скажем тач-эвентов ?
Вот, вопрос по делу
Для этого есть синтаксис <div event-*="$Handler" />, где вместо звёздочки название события. В обработчике можно пользоваться объектом event, который передаётся через параметры.