Re[18]: Дерево для rsdn.ru созданнео на NemerleWeb
От: GreenTea  
Дата: 02.07.13 19:26
Оценка:
Здравствуйте, _NN_, Вы писали:

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


_NN>Все уже давно решено: Типизация JS
Автор: _NN_
Дата: 22.06.13
.


_NN>Скоро будет парсер деклараций TS 0.9 с генериками и вообще красота =)


Спасибо за ссылку, но хотелось бы увидеть более развернутые ответы по каждому из вопросов.
Re[17]: Дерево для rsdn.ru созданнео на NemerleWeb
От: _NN_ www.nemerleweb.com
Дата: 02.07.13 19:47
Оценка:
Здравствуйте, GreenTea, Вы писали:

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


GT>...


GT>В смысле нет джаваскрипта? Судя по http://nemerlewebsamples.apphb.com/ он генерирутся? Если так то есть следующие вопросы.

GT>1) Что если надо сделать что-то в джаваскрипте, что нельзя сделать средставами NemerleWeb? Или можно написать все что угодно и это будет скопмилировано в любой javascript?
js macro:
F() : void
{
 js <# произвольный js код #>;
}

GT>2) Как быть с джаваскриптовыми библиотеками и компонентами. Например jQuery и его плагины, можно ли их использовать? Ведь написаны тысячи бесплатных и очень качественных джаваскриптовых конролов и компонент, под любые задачи.
Как было указано, есть типизация JS, вручную либо через автоматическую генерацию из описаний TypeScript.
GT>3) Можно ли писать код активно взаимодействующий с браузером? Имею в виду подписываться на эвенты браузера, использовать file api, history api. Можно ли писать код специфичный для браузера (например реализовать какой-то воркэраунд для IE8 который много чего не поддеривает?
После 2-го пункта конечно.
Пример:

using NemerleWeb.TypedJS;

F() : void
{
  window.setTimeout(() => { ...} , 11);    
}


GT>4) Если наблюдается некая бага в динамической части сайта, то часто способ ее решения это в консоли браузера поиграться с джаваскриптовыми функциями (а я знаю с какими, ведь я их сам писал), и посмотреть, что получается. Как быть в случае немерле веб, смогу ли я с легкостью разобраться со сгенерированными джаваскриптами и поиграться с ними. А если найду баг в джаваскрипте, то легко ли мне будет найти код, который сгенерировал этот джаваскрипт? А если выяснится что бага в генераторе джаваскрипта?

Если есть бага, то найти несложно да и тесты можно всегда написать.

Генерация кода из юнита довольна проста, разве что из сопоставления с образцом сгенерирует еще тот код
Код (nweb.js) не сложен тоже, не хватает разве что документации там.

GT>Более философский вопрос.

GT>5) Допустим я решил поменять работу, и на новой работе не используют немерле, но больше традиционные подходы к веб программированию. Смогу ли я применить свой опыт в традиционных проектах? Или придется переучиваться и перестраивать мышление?
После Nemerle вам будет трудно программировать на менее мощных языках.
Я считаю , что сможете конечно.
Тот же AngularJS предоставляет MVVM , но он работает через JS, а значит менее типизирован.

GT>Лично я джаваскрипт ненавижу, убогий язык.. И рад бы если бы появилось в вебе что-то более полноценное (статически типизированное, с поддержкой ООП). Но столько на нем всего написано сейчас, что эта мечта кажется из области фантастики.

Во первых сейчас есть TypeScript. Он вполне себе ничего.
А если хотите серьезного кода с сопоставлением с образцом, алгебраическими типами и макросами, то NemerleWeb все может
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[18]: Дерево для rsdn.ru созданнео на NemerleWeb
От: GreenTea  
Дата: 02.07.13 20:07
Оценка:
Здравствуйте, VladD2, Вы писали:

...

Понятно, спасибо.

Я поэтому и спросил про генерацию javascript-а, потому что, то как сделан к примеру GWT — рвет все шаблоны традиционному веб разработчику. Писал маленький проектик для себя, так и не дописал. Слишком все заумно и не привычно делается..


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

http://blueimp.github.io/jQuery-File-Upload/
http://jqueryui.com/datepicker/
http://jqueryui.com/autocomplete/
и другие из jquery

http://arshaw.com/fullcalendar/
http://ckeditor.com/demo

Сходу написать такое — при всем уважении к NemerleWeb — не получится..

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

Вобщем надо Nemerle Web попробовать на реальном проекте. Я бы вам посоветовал, может кто-то из разрабочиков Nemerle WEB писал какой-то несложный сайт на ASP .NET или, если пришли из мира java — на jsp, или ruby on rails (что сейчас популярно). Так вот, возьмите этот проект, и портируйте на Nemele Web. Чтобы функционально сайт был полным клоном. И провести сравнительный анализ трудозатрат. Сразу будет видно где убивалось сложности в разработке, где добавилось. Вопервых, это будет хорошая пища для ума и источник идей для разработчиков Nemerle Web. Потому, можно потом написать статью по этому поводу куда нибудь на хабр, или приготовить доклад на какую-нибудь IT конференцию. Если действительно получается намного проще — то будет вам хорошая реклама. Самое главное, что это будет доступно для восприятия. Традиционные веб разрабочики поймут насколько Nemerle Web крут в сравнении с обычным подходом, не на словах, а в реальном проекте..
Re[19]: Дерево для rsdn.ru созданнео на NemerleWeb
От: _NN_ www.nemerleweb.com
Дата: 02.07.13 20:39
Оценка:
Здравствуйте, GreenTea, Вы писали:

GT>Получается над сторонними компонентами на джаваскрипте придется писать обертки. Немножко пугает.

Можете не писать, а фигачить яваскрипт. Никто не запрещает использовать оба подхода.
Скорее всего для них уже написана типизация в виде TypeScript, а значит NemreleWeb подхватит автоматом.

GT>Приведу примеры таких компонент которыми активно пользовался:


GT>http://blueimp.github.io/jQuery-File-Upload/

GT>http://jqueryui.com/datepicker/
Готовая типизация на TypeScript:
interface JQueryDatePickerDefaults {
    closeText: string;
    prevText: string;
    nextText: string;
    currentText: string;
    monthNames: string[];
    monthNamesShort: string[];
    dayNames: string[];
    dayNamesShort: string[];
    dayNamesMin: string[];
    weekHeader: string;
    dateFormat: string;
    firstDay: number;
    isRTL: bool;
    showMonthAfterYear: bool;
    yearSuffix: string;
}


GT>http://jqueryui.com/autocomplete/

GT>и другие из jquery
Большинство уже сидит в NuGet с типизацией.

GT>http://arshaw.com/fullcalendar/

GT>http://ckeditor.com/demo
Либо кто-то написал, либо легко сгенерировать типизацию и пользоваться.

GT>Сходу написать такое — при всем уважении к NemerleWeb — не получится..

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

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


GT>Вобщем надо Nemerle Web попробовать на реальном проекте. Я бы вам посоветовал, может кто-то из разрабочиков Nemerle WEB писал какой-то несложный сайт на ASP .NET или, если пришли из мира java — на jsp, или ruby on rails (что сейчас популярно). Так вот, возьмите этот проект, и портируйте на Nemele Web. Чтобы функционально сайт был полным клоном. И провести сравнительный анализ трудозатрат. Сразу будет видно где убивалось сложности в разработке, где добавилось. Вопервых, это будет хорошая пища для ума и источник идей для разработчиков Nemerle Web. Потому, можно потом написать статью по этому поводу куда нибудь на хабр, или приготовить доклад на какую-нибудь IT конференцию. Если действительно получается намного проще — то будет вам хорошая реклама. Самое главное, что это будет доступно для восприятия. Традиционные веб разрабочики поймут насколько Nemerle Web крут в сравнении с обычным подходом, не на словах, а в реальном проекте..


Создание дерева для RSDN вполне реальный проект.
И если в итоге этот код заменит оригинальный на этом форуме, разве это не достаточно показательно ?
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[17]: И вообще...
От: ionoy Эстония www.ammyui.com
Дата: 03.07.13 08:05
Оценка:
Здравствуйте, Mamut, Вы писали:

_NN>>Скажем вот:

_NN>>
<span class="node-caption" css-is-active="$(MainPage.Instance.IsActiveNode(c))">

_NN>>Как по другому предлагается это реализовать ?

M> Нафига это в шаблоне? Что такое css-is-active? Что за невнятные и непонятные расширения HTMLя?

А как ты предлагаешь реализовать биндинг:

//псевдокод
if(MainPage.Insance.IsActiveNode(c))
  el.addClass("is-active");
else
  el.removeClass("is-active");


M>1. Вынести это в отдельный файл (верстальщику/дизайнеру вообще даром не упал ни Nemerle, ни студия, ни компиляция)

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

M>2. Свести как можно ближе к стандартному HTMLю. Всякое css-is-active, attr-src, css-pinned, style-margin-left, attr-href, css-with-children, css-selected-search-result — в топку.

attr-* — в топку, согласен. Можно заменить на голые href, src и так далее.
А вот с остальным не так просто. Попробуй предложи, как более красиво биндить style или css.

M>3. Убрать всю императивщину из HTMLя нафиг (MainPage.Instance.IsActiveNode? Вы с дуба рухнули?).

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

M>И вообще протягивать внутрь представления вообще всю логику, что реализована в Nemerle — тоже в топку.

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

M>4. В шаблон передается ограниченный набор переменных и ограниченный набор инструментов манипуляции с ними, которые легко понять и легко выучить, и с которыми верстальщик может играться как ему угодно. Что-то типа <span class="node-caption {% if active_node == node %} node-active {% endif %}" >

Ну вот, ты заменил лаконичный css-node-active="$(active_node == node)" на какую-то кашу из if/endif и кучу ненужных символов.

_NN>>Еще раз, для улучшения библиотеки хочется понять как это должно быть, чтобы не "менять код".

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

M>Смогут ли они управлять внешним видом UI только с помощью CSS-а, получая произвольный код от программистов? Если нет (а ответ: нет, конечно), то надо давать возможность править HTML максимально безболезненно


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

M>
M><div $foreach(c in Children) style-margin-left="$(c.Depth * 6)" class="node" css-selected-search-result="$(c.IsSelected)">
M>          <a click="$(c.CaptionClick())" attr-href="$("http://www.rsdn.ru" + c.Href)" css-with-children="$(c.HasChildren)">
M>            <img class="node-icon" attr-src="$(c.IconUrl)" />
M>            <span class="node-caption" css-is-active="$(MainPage.Instance.IsActiveNode(c))">
M>              $(c.Caption)
M>            </span>
M>            <div $when(!c.HasChildren) click="$(c.TogglePin())" class="node-pin" css-pinned="$(MainPage.Instance.IsPinned(c))" />
M>          </a>
M>          <div $when(c.IsLoading) class="node-loading">
M>            Загрузка, пожалуйста подождите...
M>          </div>
M>          <div $when(c.IsOpened && Children != null)>
M>            <div template="$(template(c))" />
M>          </div>
M>        </div>
M>


M>Ни один «немножечко программист» эти вьюхи не осилит, потому что они наугад вносят какие-то расширения к HTMLю, которые берутся неизвестно откуда. Соответсвенно, надо упрощать, смотреть, как это делается в других шаблонных движках.


Если бы ты прочитал туториал, то понял бы, что ничего сложного в css-*/style-* нет. Вьюха выглядит на первый взгляд монструзно, но это только от того, что это достаточно сложный шаблон с кучей зависимостей от данных. Если бы ты это переписал в jQuery, то у тебя получилась бы простыня на три-четыре страницы плохо поддерживаемого императивного кода.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[18]: И вообще...
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.13 10:51
Оценка:
Здравствуйте, ionoy, Вы писали:

I>attr-* — в топку, согласен. Можно заменить на голые href, src и так далее.

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

Можно поступать следующим образом. Если значение атрибута/стиля null, то автоматом не включать его в конечный ХТМЛ. Для выбора можно разрешить использование if внутри атрибутов и стилей. Опять же если возвращенное значение null, то делаем вид что его никогда не было.

I>Нет, не рухнули. Можно конечно в отдельное свойство вынести


Нужно.

I>(первоначально так и было), но сути это не изменит.


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

M>>4. В шаблон передается ограниченный набор переменных и ограниченный набор инструментов манипуляции с ними, которые легко понять и легко выучить, и с которыми верстальщик может играться как ему угодно. Что-то типа <span class="node-caption {% if active_node == node %} node-active {% endif %}" >

I>Ну вот, ты заменил лаконичный css-node-active="$(active_node == node)" на какую-то кашу из if/endif и кучу ненужных символов.

Ненужные символы можно и убрать.
<span class="active_node == node ? node-caption : node-active" >

А более правильный подход вынести всю логику в свойство:
[Unit]
public class TreeNode
{
  public Style : string { get { if (MainPage.Instance.IsActiveNode(c)) "is-active" else "node-caption" } }
  ...
  [Html]
  public View() : string
  {
    <#
      ...
      <span class="$Style" >
      ...
    #>


На мой взгляд так намного лучше.

Если же нужно вообще не задавать стиль, то возвращаем null
[Unit]
public class TreeNode
{
  public Style : string { get { if (MainPage.Instance.IsActiveNode(c)) "is-active" else null } }
  ...
  [Html]
  public View() : string
  {
    <#
      ...
      <span class="$Style" > <!-- Если Style вернет null, то атрибут class удаляется. -->
      ...
    #>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: И вообще...
От: ionoy Эстония www.ammyui.com
Дата: 03.07.13 14:51
Оценка:
Здравствуйте, VladD2, Вы писали:

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


I>>attr-* — в топку, согласен. Можно заменить на голые href, src и так далее.

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

VD>Можно поступать следующим образом. Если значение атрибута/стиля null, то автоматом не включать его в конечный ХТМЛ. Для выбора можно разрешить использование if внутри атрибутов и стилей. Опять же если возвращенное значение null, то делаем вид что его никогда не было.


Видимо, возникло недопонимание в том, как работают эти атрибуты.

Условные классы:
<div css-{className}="{condition}" />

Если {condition} == true, то к div будет добавлен класс {className}. Если {condition} == false или не определён, то класс {className} добавлен не будет, либо будет удалён, если он там раньше был.
Это избавляет от необходимости писать if/else внутри атрибута.
Динамически формировать атрибут class можно через attr-class="{classNames}". Впоследствие можно будет заменить на class="{classNames}".

Значения свойств:
<div style-{styleName}="{styleValue}" />

Подобная запись будет аналогом:

$(el).css(styleName, styleValue)


Только обновлятся будет автоматически.

VD>Ненужные символы можно и убрать.

VD>
VD><span class="active_node == node ? node-caption : node-active" >
VD>...
VD>

Тут node-active должен добавлятся к node-action, а не заменять его, так что в текущей реализации будет работать так:

<div attr-class="$(if(active_node == node) "node_caption" else "node_caption node-active")" />


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

VD>Если же нужно вообще не задавать стиль, то возвращаем null

Это автоматом работает, если я не ошибаюсь.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[20]: И вообще...
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.13 16:41
Оценка:
Здравствуйте, ionoy, Вы писали:

I>Видимо, возникло недопонимание в том, как работают эти атрибуты.


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

I>Условные классы:

I>
I><div css-{className}="{condition}" /> 
I>

I>Если {condition} == true, то к div будет добавлен класс {className}. Если {condition} == false или не определён, то класс {className} добавлен не будет, либо будет удалён, если он там раньше был.
I>Это избавляет от необходимости писать if/else внутри атрибута.
I>Динамически формировать атрибут class можно через attr-class="{classNames}". Впоследствие можно будет заменить на class="{classNames}".

Дык о почему не перенести condition в свойство модели представления и не возвращать null, если он не нужен (изымается)?
Тогда то что тебе нужно можно было бы записать как-то так:
public ActiveClass : string { get { if (MainPage.Instance.IsActiveNode(this)) "node-active" else null } }
...
<div class="node-caption $ActiveClass" />

?
Тогда, если узел текущий (активный), свойство ActiveClass возвратит "node-active" и окончательное значение атрибута class будет "node-caption node-active", а если нет, то ActiveClass возвратит null и окончательное значение атрибута class будет "node-caption".

Получится интуитивно понятно и просто.

I>Значения свойств:

I>
I><div style-{styleName}="{styleValue}" />
I>

I>Подобная запись будет аналогом:

I>
I>$(el).css(styleName, styleValue)
I>


I>Только обновлятся будет автоматически.


Я в jQuery не силен. Как это будет выглядеть в HTML-е?

VD>>Если же нужно вообще не задавать стиль, то возвращаем null

I>Это автоматом работает, если я не ошибаюсь.

Тогда в чем проблема? Почему его не использовать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: И вообще...
От: ionoy Эстония www.ammyui.com
Дата: 04.07.13 07:32
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Дык о почему не перенести condition в свойство модели представления и не возвращать null, если он не нужен (изымается)?

VD>Тогда то что тебе нужно можно было бы записать как-то так:
VD>
VD>public ActiveClass : string { get { if (MainPage.Instance.IsActiveNode(this)) "node-active" else null } }
VD>...
VD><div class="node-caption $ActiveClass" /> 
VD>

VD>?
VD>Тогда, если узел текущий (активный), свойство ActiveClass возвратит "node-active" и окончательное значение атрибута class будет "node-caption node-active", а если нет, то ActiveClass возвратит null и окончательное значение атрибута class будет "node-caption".
Ты это можешь делать и сейчас, но такой подход мне не нравится, так как он вносит в модель знания о представлении. На стороне сервера ActiveClass не будет иметь никакого смысла.

VD>Получится интуитивно понятно и просто.

Для тех кто хочет так делать, возможность уже есть и сейчас.

Объясню, почему был добавлен подобный синтаксис.
Дело в том, что чаще всего нужны именно классы-флаги, которые добавляются/убираются в зависимости от состояния страницы. Нажал пользователь на кнопку, сделали какой-то элемент активным, нажал другую убрали статус активности. Обычно это выливалось в подобный код:

$btn1.click(function() {
  $el.addClass("active");
});

$btn2.click(function() {
  $el.removeClass("active");
});


Довольно редко нужно формировать название класса, так как они жёстко заданы в css файле.
Запись css-is-active="$IsActive" оставляет нашу модель чистой и при этом чётко связывает класс-флаг "is-active" с состоянием свойства IsActive. Таким образом, мы одной короткой и декларативной записью показываем наши намерения.

I>>
I>>$(el).css(styleName, styleValue)
I>>


I>>Только обновлятся будет автоматически.


VD>Я в jQuery не силен. Как это будет выглядеть в HTML-е?

Просто устанавливаем значение css property http://api.jquery.com/css/

VD>>>Если же нужно вообще не задавать стиль, то возвращаем null

I>>Это автоматом работает, если я не ошибаюсь.
VD>Тогда в чем проблема? Почему его не использовать?
Потому что, по моему мнению, это более грязный вариант, несмотря на то, что он может быть более понятным для человека, который в первый раз видит фреймворк.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[22]: И вообще...
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.07.13 10:52
Оценка:
Здравствуйте, ionoy, Вы писали:

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


На то она и модель представления. Да и знанием это не назовешь. Знает — это когда модели нужен доступ к представлению.

Твое предпочтение никаких выгод не дает, но ты его предерживашся потому как "есть мнение". Это похоже на догму.

VD>>Получится интуитивно понятно и просто.

I>Для тех кто хочет так делать, возможность уже есть и сейчас.

ОК. Это хорошая позиция. Вот это и надо показать/объяснить.

I>Объясню, почему был добавлен подобный синтаксис.

I>Дело в том, что чаще всего нужны именно классы-флаги, которые добавляются/убираются в зависимости от состояния страницы. Нажал пользователь на кнопку, сделали какой-то элемент активным, нажал другую убрали статус активности. Обычно это выливалось в подобный код:

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

I>Запись css-is-active="$IsActive" оставляет нашу модель чистой и при этом чётко связывает класс-флаг "is-active" с состоянием свойства IsActive.


Не уверен, что "оставляет нашу модель чистой" является преимуществом над "загрязняет наше представление". Точнее уверен в обратном.

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

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


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

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


Ага. Если концепции противоречат здравому смыслу, то нужно менять здравый смысл.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: И вообще...
От: ionoy Эстония www.ammyui.com
Дата: 04.07.13 13:02
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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

VD>На то она и модель представления. Да и знанием это не назовешь. Знает — это когда модели нужен доступ к представлению.
Суть в том, что класс is-active — это часть представления, а не модели. Поэтому получается хоть и небольшая, но протечка из представления в модель.

VD>Твое предпочтение никаких выгод не дает, но ты его предерживашся потому как "есть мнение". Это похоже на догму.

Почему это не даёт? Мой код короче в несколько раз и понятнее для человека познакомившегося с синтаксисом. Пока флаг только один, то может и не проблема добавить строковое свойство, но когда представление вырастет, то там может быть штук 10 таких флагов. Писать для каждого из них отдельное свойство — это в моём понимании грязь.

I>>Объясню, почему был добавлен подобный синтаксис.

I>>Дело в том, что чаще всего нужны именно классы-флаги, которые добавляются/убираются в зависимости от состояния страницы. Нажал пользователь на кнопку, сделали какой-то элемент активным, нажал другую убрали статус активности. Обычно это выливалось в подобный код:
VD>А почему вы не предпочли подход из Нокаута? Там вроде как для стилей биндинг был.
Сюрприз: data-bind="css: { profitWarning: currentProfit() < 0 }"

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

Ну куда уж проще css-profitWarning="$(currentProfit < 0)"?

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

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

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

VD>Ага. Если концепции противоречат здравому смыслу, то нужно менять здравый смысл.
А где наша концепция противоречит здравому смыслу? Как раз наоборот, она отлично обоснована и выполняет свою задачу.
Она может быть непонятна для тех, кто её в первый раз видит, но это с большинством технологий так. Если человек всю жизнь программировал на ассемблере, то для него и лябмда может противоречить здравому смыслу. Что же теперь, всем под него подстраиваться?
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[17]: Дерево для rsdn.ru созданнео на NemerleWeb
От: Ziaw Россия  
Дата: 07.07.13 05:13
Оценка:
Здравствуйте, GreenTea, Вы писали:

GT>Лично я джаваскрипт ненавижу, убогий язык.. И рад бы если бы появилось в вебе что-то более полноценное (статически типизированное, с поддержкой ООП). Но столько на нем всего написано сейчас, что эта мечта кажется из области фантастики.


Язык как язык. Поддержка ООП есть в CoffeeScript и TypeScript. Второй, вдобавок, статически типизирован.
Re[27]: И вообще...
От: Mamut Швеция http://dmitriid.com
Дата: 28.07.13 15:58
Оценка: 4 (2)
WH>>Те все твои претензии сводятся к тому, что конкретные примеры, написаны не так как тебе нравится?

VD>Ему просто по флэймить охота. У него натура такая.


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


Я тут ушел с РСДН, но здесь решил отметить все же один раз. У вас дичайшие проблемы с популяризацией своих детищ.

Просто попытайся разобраться в том что такое НемерлВеб. Уверяю тебя ты даже не представляешь насколько он круче.
прочти что там написано и попытайся понять.
До тех пор пока ты не разберешься что же такое MVVM спорить с тобой бесполезно.


И т.п.

Про уровень информации про N2 я вообще промолчу, ее надо собирать по крупицам внутри десятка подветок.

Но, как всегда — все тупые и не понимают мегагениальности художников.

Предсказываю: и через год и через два вы будете все так же «мотать на ус» и обижаться на людей, которые требуют от вас внятной информации, а не позиции «мы д'Артаньяны, а вы — тупые и ничего не понимаете».


dmitriid.comGitHubLinkedIn
Re[28]: И вообще...
От: ionoy Эстония www.ammyui.com
Дата: 29.07.13 13:55
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Я тут ушел с РСДН, но здесь решил отметить все же один раз. У вас дичайшие проблемы с популяризацией своих детищ.

M>...

Ты прав в целом, но не неправ в конкретном случае. Для NemerleWeb написан нормальный туториал, который объясняет все основные моменты работы фреймворка.
Другое дело, что не все хотят его читать, но мнение уже имеют. Вот и выходят недопонимания.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[29]: И вообще...
От: Mamut Швеция http://dmitriid.com
Дата: 29.07.13 15:38
Оценка:
M>>Я тут ушел с РСДН, но здесь решил отметить все же один раз. У вас дичайшие проблемы с популяризацией своих детищ.
M>>...

I>Ты прав в целом, но не неправ в конкретном случае. Для NemerleWeb написан нормальный туториал, который объясняет все основные моменты работы фреймворка.

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

Я его прочитал. Весь. Увидел, что там на каждый чих надо лопатить HTML. Об этом и сказал. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».

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

Пока что я вижу:
— с одной стороны истеричные вопли «оно круче всего, оно позволяет легко и непринужденно создавать сложные веб-приложения!»
— с другой — туториал, где для простейших действий надо лопатить HTML руками, без единого объяснения, зачем оно нужно, чем это круче приведенного вначале туторияла jQuery и вообще нафиг оно такое нужно в таком виде.

На фоне второго первое выглядит, мягко говоря, смешно.

Но да, я «в данном конкретном случае неправ», потому что «...тут вставить все user-friendly заявления Влада...».



Пару примеров. Например, ваш туториал лжет:

NemerleWeb is Model-View-ViewModel framework that simplifies creating dynamic web pages.
You write your code in Nemerle or other front-end language like C#, then it gets translated into mixture of javascript, html and server side classes.


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



And while this code looks simple enough, it has it’s flaws.

First of all it’s highly jQuery specific. You are not operating inside your problem domain, which is ToDo List, but rather dealing with DOM structure and events.


Да неужели!

[Html]
View() : string
{
  <#
    <input value="$TaskToAdd.Title" />
    <span visibility="$(!TitleIsLongEnough(TaskToAdd))" class="validation-error">Title is not long enough</span>
    <input value="$TaskToAdd.Priority" />
    <span visibility="$(!PriorityIsPositive(TaskToAdd))" class="validation-error">Priority should be positive</span>
    <button click="$AddTask" enabled="$(ValidateTask(TaskToAdd))" />
    <ul $foreach(t in Tasks.OrderBy(t => t.Priority))>
      <li>
   $(t.Priority): $(t.Title)
   <input type="checkbox" checked="$(t.Status)" />
      </li>
    </ul>
  #>
}


Вот везде, ну абсолютно везде я "write your code in Nemerle or other front-end language like C#", "operating inside your problem domain" и не "dealing with DOM structure and events.". Вот прямо везде.



И так — на протяжение всего туториала. Но да, но да. «не все хотят его читать, но мнение уже имеют.» Вы не попытались подумать хотя бы на секунду, что люди — да, таки читают то, что вы пишете. И то, что вы пишете, приносит вашим же проектам в разы больше вреда, чем люди, «которые имеют свое мнение»?


Напомнило. http://discuss.emberjs.com/t/getting-started-with-ember-js-is-easy-no-it-isnt/559/17


dmitriid.comGitHubLinkedIn
Re[30]: И вообще...
От: ionoy Эстония www.ammyui.com
Дата: 29.07.13 17:27
Оценка: +2
Здравствуйте, Mamut, Вы писали:

M>Я его прочитал. Весь. Увидел, что там на каждый чих надо лопатить HTML.

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

M>Об этом и сказал. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».

Потому что ты так до сих пор и не понял, какая цель этого фреймворка. Посмотри на AngularJS, Meteor и подобные проекты. Там точно такой же HTML и точно такой же биндинг — только синтаксис другой.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[31]: И вообще...
От: Mamut Швеция http://dmitriid.com
Дата: 30.07.13 15:03
Оценка: 1 (1)
M>>Я его прочитал. Весь. Увидел, что там на каждый чих надо лопатить HTML.
I>Лопатить HTML придётся, это же реактивный веб фреймворк, а не набор готовых компонентов. Для веб разработчика это не должно быть проблемой.
I>Идеология фреймворка в том, что мы вносим как можно меньше своих примитивов. Фактически, кроме директив, без которых не обойтись, фреймворк не добавляет.

Вау. И почему я об этом должен читать на стопятьсотой подветке на РСДН, а не в «туториале, в котором все написано, разбирайтесь»?

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


Это — ложь, потому что HTML'я надо писать тоже много. У вас весь туториал состоит из того, как вы меняете HTML.


M>>Об этом и сказал. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».

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

О. Ты как раз ответил выделенным.

Кто-то где-то описал, что это, зачем это нужно, и чем оно отличается от других? Нет. Вините сами себя.


I>Посмотри на AngularJS, Meteor и подобные проекты. Там точно такой же HTML и точно такой же биндинг — только синтаксис другой.


Они не лгут в своих туториалах, они ясно описывают свои цели, они четко описывают свои туториалы и говорят, что к чему, и почему это лучше существующего.

"Read tutorial. It is not complete yet. Feel free to comment." Мы комментируем. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».


dmitriid.comGitHubLinkedIn
Re[32]: И вообще...
От: _NN_ www.nemerleweb.com
Дата: 30.07.13 15:46
Оценка:
Здравствуйте, Mamut, Вы писали:

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


M>Это — ложь, потому что HTML'я надо писать тоже много. У вас весь туториал состоит из того, как вы меняете HTML.

Снова по кругу ?
Почему не написать в стиле: "Вместо того чтобы менять HTML , лучше делать так и так потому эдак и эдак".

Пока высказался только avpavlov о том, что неудобно когда HTML в том же файле что и код.
Этот аргумент вполне принимается, и в будущем попробуем сделать более удобную работу с этим.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[32]: И вообще...
От: ionoy Эстония www.ammyui.com
Дата: 30.07.13 16:07
Оценка:
Здравствуйте, Mamut, Вы писали:

I>>Посмотри на AngularJS, Meteor и подобные проекты. Там точно такой же HTML и точно такой же биндинг — только синтаксис другой.


M>Они не лгут в своих туториалах, они ясно описывают свои цели, они четко описывают свои туториалы и говорят, что к чему, и почему это лучше существующего.


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

M>"Read tutorial. It is not complete yet. Feel free to comment." Мы комментируем. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».


Слушай, может хватит уже обижаться? Ты ведь сам пишешь в провокационном тоне, но выходит так, что все вокруг грубияны, а ты весь такой в белом плаще красивый.
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Re[33]: И вообще...
От: Mamut Швеция http://dmitriid.com
Дата: 20.08.13 20:52
Оценка:
I>>>Посмотри на AngularJS, Meteor и подобные проекты. Там точно такой же HTML и точно такой же биндинг — только синтаксис другой.

M>>Они не лгут в своих туториалах, они ясно описывают свои цели, они четко описывают свои туториалы и говорят, что к чему, и почему это лучше существующего.


I>То есть проблема всё-таки в туториале, а не в фреймворке?


Мне про фреймворк ничего неизвестно. Кроме туториала. В котором про фрейморк вообще ничего внятного не говорится. Замкнутый круг.

I>Если так, то как человек со стороны ты мог бы предложить как его улучшить. Честное слово, были бы очень благодарны. Писать туториал дело непростое, так как тяжело поставить себя на место разработчика, который видит фреймворк впервые. К тому же общие знания о теме у всех разные, что ты в этой ветке показал.



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

M>>"Read tutorial. It is not complete yet. Feel free to comment." Мы комментируем. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».


I>Слушай, может хватит уже обижаться? Ты ведь сам пишешь в провокационном тоне, но выходит так, что все вокруг грубияны, а ты весь такой в белом плаще красивый.


Я — обычный программист пришел пользоваться вашим СВЕРХСУПЕРМЕГАПРОДУКТОМ. Вместо этого мне подсовывают... неизвестно никому, что вы мне подсовываете, кроме воплей про СУПЕРМЕГАПРОДУКТ и туториал про лопачение HTMLя на каждый чих.

В последних трех-четырех сообщениях я последовательно говорил о проблемах с туториалом и описаниями. Где благодарность? Не вижу. Вижу только "ты тупой, иди читай туториал". Более того, тут: http://rsdn.ru/forum/nemerle/5245188.1
Автор: Mamut
Дата: 29.07.13
я привел примеры проблем. Где благодарность? Нету. "Потому что ты так до сих пор и не понял, какая цель этого фреймворка." По ходу, он настолько мега-гениальный, что цель этого фреймворка известна только вам.


dmitriid.comGitHubLinkedIn
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.