Re[18]: Дерево для rsdn.ru созданнео на NemerleWeb - Nemerle

Помнится, Влад предлагал сделать на NemerleWeb новое дерево/меню для rsdn.ru.

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

Если кому интересно, посмотреть можно здесь: http://m.rsdn.ru
Самое интересное — это код. Вся структура меню состоит из трёх Unit'ов

1. MainPage https://github.com/NemerleWeb/NemerleWeb/blob/master/NemerleWeb.RSDN/MVVM/MainPage.n
Здесь рендерится общая структура страницы: левая часть (поиск, прикреплённые ветки, меню) и правая, которая содержит iframe для страниц rsdn.

2. TreeNode https://github.com/NemerleWeb/NemerleWeb/blob/master/NemerleWeb.RSDN/MVVM/TreeNode.n
Собственно, нода. Всё что она делает — это рендерит свои под-ноды и подгружает их по мере надобности. Одновременно является объектом, который используется как на сервере, так и на клиенте.

3. Search https://github.com/NemerleWeb/NemerleWeb/blob/master/NemerleWeb.RSDN/MVVM/Search.n
Поиск. Тут стоит обратить внимание на макрос throttle, который генерирует код примерно следующего содержания:

window.clearTimeout(_timeout1);
_timeout1 = window.setTimeout(() => {
  ...code...
}, 500)

При этом генерируется поле _timeout{X} для каждого отдельного throttle.

На сервере есть ещё всего один "лишний" класс, который отвечает за загрузку дерева в память: https://github.com/NemerleWeb/NemerleWeb/blob/master/NemerleWeb.RSDN/Models/TreeLoader.n

Всё остальное генерируется фреймворком.

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

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

M>>То, что у вас MVVM никак не отменяет того факта, что это — захардкоженный HTML, который еще верстать надо. От того, что вы к нему приклеили foreach, возможности вызова Nemerle-кода и кой-какую генерацию JS, никак не отменяет того факта, что это — захардкоженный HTML, требующий верстки и изменения на каждый мало-мальский чих.
F> Кстати, а кто ещё умеет немножко генерить JS? Ну GWT не берём — я его ниасиливаю.

Например, liftweb

Викет умеет, правда он на Яве и слегка многословно смотрится.

WH>>Те все твои претензии сводятся к тому, что конкретные примеры, написаны не так как тебе нравится?

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

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

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

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

И т.п.

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

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

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

_NN>Не совсем понимаю.
_NN>У нас есть логика представления, скажем, показывать или не показывать <div>.
_NN>Это зависит от какой-нибудь переменной , скажем X.
_NN>Завтра она меняется на Y или ну другую логику, и "надо привлекать программиста".

_NN>Давай более развернутый пример.
_NN>Что было, как мы хотим это изменить, и каким образом не нужен программист.

Для этого нужен программист, а для правки ХТМЛ и стилей нужен верстальщик и ему удобнее оперировать голым ХТМЛ и ЦСС.

Задача хорошего шаблонного движка сделать так, чтобы они

1) правили разные файлы
2) верстальщику не нужно компилировать и перезапускать приложение
3) в супер-супер идеале верстальщику не нужно запускать приложение, а нужно просто открыть хтмл в броузере.

Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко. Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф. Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. Но если я правильно понимаю, то система макросов в Немерле такое не потянет, поэтому вы пишете просто "ещё один движок", который в чём-то лучше, в чём-то такой же, в чём-то хуже остальных.

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

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

M>Об этом и сказал. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».
Потому что ты так до сих пор и не понял, какая цель этого фреймворка. Посмотри на AngularJS, Meteor и подобные проекты. Там точно такой же HTML и точно такой же биндинг — только синтаксис другой.

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

_NN>>Оперу еще никто не проверял.

_NN>>Может знаете в чем причина ? Скорее всего там стиль нужно подправить и оно заработает.

А>

А>.node .node-caption {
А> display: block;
А> margin-left: 35px;
А> margin-right: 26px;
А>}

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

Можно заменить на

padding-right: 26 px;

В этом случае это будет внутренний отступ от границы и это пространство будет принадлежать элементу node-caption и ховер будет работать.

_NN><css-is-active="$X" css-is-not-active="$(!X)">
_NN>Что тут он хочет видеть ? Первое или второе ?

Он хочет видеть и первое и второе, посмотри мой пример.

В Викете в некоторых моментах именно так и сделано, посмотри пример

http://wicket.apache.org/learn/examples/dropdownchoice.html

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

_NN>Ну или аналогично с атрибутами:
_NN><a attr-href="$("/" + $Something") />
_NN>Где планируется передаваться ссылка ?
_NN>Если предлагается
_NN><a href="$Something" />
_NN>Так можно делать и сейчас.

Реальные ссылки верстальщику не особо нужны.

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." Мы комментируем. Что в ответ? «Ты тупой, иди читай, иди разбирайся, оно настолько круто, что ты нихера не понимаешь».

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

I>Помнится, Влад предлагал сделать на NemerleWeb новое дерево/меню для rsdn.ru.

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

Отличная работа! Идея с пинед-ветками вообще замечательная.

Но есть ряд замечаний.

1. Активная ветка не выделяется визуально. По сему невозможно понять, что сейчас открыто.
2. Во вложенных элементах слишком большой отступ. Ветки уезжают вправо. Надо сделать меньших отступ. Плюсы должны начинаться сразу по окочании плюсов родительского дерева.
3. Нужно показывать кнопочки для запиненых веток в дереве (не только при наведении мыши, а всегда).
4. В окне поиска хорошо бы показывать подсказку (как в окне навигации броузера).
5. При нажатии элемента с шифтом соответствующая страница должна открываться в отдельной закладке броузера (старая версия ведет себя именно так).
6. При попытке посмотреть дерево в броузере телефона, в портретном режиме размер места отводимого под дерево был столь урезан, что текст не вмещался. В альбомном (повернутом на бок) режиме тот же эффект наблюдается если открыть ветку по глубже. Нужно с этим побороться. И вообще, нужно сделать так чтобы в телефоне деревом было пользоваться так же удобно как и на компьютере.
7. Цвета не очень. Но это уже фигня.
8. Настройки нужно хранить не в куках, а не сервере. Это не дело когда на каждом девайсе нужно настраивать окружение. Доложно быть так — залогинился и работаешь со своим окружением на любом машине в любом броузере.
9. Вообще нет вертикального сплитера, так что изменить размеры окна не получается. В мобильном режиме сплитеры вообще не нужны. Долно показываться только дерево, а другие страницы всегда отрываться в новых закладках/окнах. Плюс размеры элементов в мобильном режиме должны быть крупнее, чтобы в них можно было попадать пальцем.

Вот это:

    public IconUrl : string 
    {      
      get {        
        def suffix = match(IsOpened, HasChildren) {
                      | (false, true) => "c.gif" 
                      | (true, _) => "o.gif";
                      | _ => "s.gif";
                     };
        "http://rsdn.ru/images/tree/" + Icon + suffix;
      }
    }

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

ЗЫ

Могу дать доступ на сервер рсдн, чтобы страница работала прямо на нем.

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

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

_NN>А так вбил в поиск, не нашлось с первого раза, выбрал категорию и нашел.

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

M>>В частности, поможет тем, что не надо будет смотреть на абсолютно ненужный ему код на Nemerle, и не надо будет знать абсолютно ненужные ему вещи типа «скомпиль и задеплой на сервер»
_NN>Примеры в студию.
_NN>Где тогда писать этот "ненужный код" ?

О боже. Любой шаблонный движок в руки.

https://docs.djangoproject.com/en/dev/ref/templates/
http://mustache.github.io
http://www.stringtemplate.org
http://www.smarty.net

да и вообще: http://en.wikipedia.org/wiki/Template_engine_(web)#Comparison

_NN>Автоматической компиляции с изменениями добиться можно относительно просто EasyMVC .

Этим же не верстальщик должен заниматься

_NN>Но без деплоя на сервер как это должно работать ?

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

_NN>Как я понимаю будет просто текстовой файл, его заливаем на сервер и вуаля все работает ?

Да.

_NN>Ну так сервер тогда может и компилировать его .
_NN>Получаем что достаточно иметь возможность автоматической перекомпиляции на сервере.
_NN>Я правильно понииаю ?

Да

_NN>Предлагайте как улучшить.

Вынести в отдельные текстовые файлы. С возможностью перезагрузки/перекомпиляции на лету.

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

Например: Помимо выноса шаблона из кода, можно избавиться от метода View(), а подцеплять шаблоны по принципу convention over configuration: класс A метод B автоматом цепляет шаблон a_b_template и т.п. На этой основе можно делать интересные вещи типа lookup hierarchy (http://zotonic.com/docs/0.9/manuals/templates/lookups.html).

Ну или посмотреть на подход Lift: http://demo.liftweb.net/templating/

VD>Это нечто вроде контролов в GUI, а не тупая печать в файл. UI получается интерактивным. Это накладывает некоторые ограничения на процесс верстки. Отдавать разработку таких вьюх дизайнерам имеет мыло смысла. Им лучше отдавать настройку css-а, с помощью которого они смогут управлять внешним видом UI.

Так вот, как только ты заставляешь программиста, а не верстальщика править HTML для создания чего-либо — фреймворк можно закапывать в землю, пока не родился. Повторю: любой залетный незакрытый <div> поломает все к чертям собачьим.

Про «дизайнеров», которые криворукий программерский HTML смогут выправить строго с помощью CSS, расскажи кому-нибудь в детском садике, да.

Примеры.

— Добавили сплиттер? меняем код
— Меняем отображение? меняем код
— Меняем высоту элемента? меняем код
— Добавили св-ство Pinned? меняем код, и пусть дизайнер удавится своим CSS
— Показываем что идет загрузка? меняем код. Боюсь представить, что произойдет, если дизайнер (!) захочет это изменить, например, на спиннер внутри текст-бокса или внутри кнопки. Ой, а если он захочет сделать A/B тест?

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

M>Так вот, как только ты заставляешь программиста, а не верстальщика править HTML для создания чего-либо — фреймворк можно закапывать в землю, пока не родился. Повторю: любой залетный незакрытый <div> поломает все к чертям собачьим.
Можешь повторять, сколько тебе влезет.
Вот только Nemerle.Web не кривой текстовый препроцессор, к которым ты привык. А нормальный компилятор.
И на незакрытый тег он тебе еще во время редактирования кода покажет. Ну и при компиляции естественно не пропустит.

Ну и попробуй понять разницу между серверным шаблонным движком коих тьма.
И клиентским MVVM которым является Nemerle.Web.

M>Боюсь представить, что произойдет, если дизайнер (!) захочет это изменить, например, на спиннер внутри текст-бокса или внутри кнопки. Ой, а если он захочет сделать A/B тест?
А что он будет делать с любым другим фреймворком? Пилить жабаскрипт?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

WH>Вот только Nemerle.Web не кривой текстовый препроцессор, к которым ты привык. А нормальный компилятор.
WH>И на незакрытый тег он тебе еще во время редактирования кода покажет. Ну и при компиляции естественно не пропустит.

Блин. Еще один. Тебе провести урок HTML 101, рассказывающий, как и каким образом можно порушить любую верстку совершенно валидным маркапом?

WH>Ну и попробуй понять разницу между серверным шаблонным движком коих тьма.
WH>И клиентским MVVM которым является Nemerle.Web.

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

M>>Боюсь представить, что произойдет, если дизайнер (!) захочет это изменить, например, на спиннер внутри текст-бокса или внутри кнопки. Ой, а если он захочет сделать A/B тест?
WH>А что он будет делать с любым другим фреймворком? Пилить жабаскрипт?

Он возьмет HTML в шаблоне и поправит HTML.

M>>Это уже меньше мешает верстальщику. Более того, верстальщик может менять дизайн/верстку, не ожидая, пока это сподобится за него сделать программист.
M>>Я имел в виду, что, по сути, для каждого телодвижения надо привлекать программиста, чтобы он правил HTML-код. Тебе не кажется, что HTML-код должен править верстальщик?

_NN>Не совсем понимаю.
_NN>У нас есть логика представления, скажем, показывать или не показывать <div>.
_NN>Это зависит от какой-нибудь переменной , скажем X.
_NN>Завтра она меняется на Y или ну другую логику, и "надо привлекать программиста".

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

_NN>Давай более развернутый пример.
_NN>Что было, как мы хотим это изменить, и каким образом не нужен программист.

Простейшие примеры уже привел.

M>>Ему его не надо ставить, и разбираться в коде яваскрипта не надо.
WH>Ага. Ага.
WH>Ты хочешь сказать, что ViewModel будет каждый раз править программист?

С вашими подходами ничего другого не остается.

M>>Да-да. Будет только захардкоженый HTML, который будет править программист, ага
WH>Чем он более захардкожен чем в knockoutjs?

В knockout-js в коде шаблона в идеале вообще не будет яваскрипта. В вашем сверхсупермегафреймворке уже внезапно

MainPage.Instance.IsActiveNode(c)
MainPage.Instance.IsPinned(c)
string.IsNullOrEmpty(SearchTerm)

Или знай Немерле или катись к черту, ага.

Здравствуйте, Mamut, Вы писали:
M>Это я не говорю об абсолютно непонятном scope контрольных инструкций $when, $foreach и т.п.

Как реализовывается список элементов не привлекая $foreach ?
KnockoutJS внезапно:

        <ul data-bind="foreach: children">
            <li>
                <span data-bind="text: $data"> </span>
                <span class='renderTime' data-bind='visible: $root.showRenderTimes'>
                    (child rendered at <span data-bind='text: new Date().getSeconds()' > </span>)
                </span>
            </li>
        </ul>

AngularJS:

<ul>
 <li ng-repeat="friend in friends">
  [{{$index + 1}}] {{friend.name}} who is {{friend.age}} years old.
 </li>
</ul>

NemerleWeb:

<tbody>
<tr $foreach(s in Seats)>
  <td><input value="$(s.Name)" /></td>
  <td>
    <select value="$(s.Meal)">
      <option $foreach(meal in AvailableMeals) value="$meal">$(meal.MealName)</option>
    </select>
  </td>
  <td>$(s.FormattedPrice)</td>
  <td><a href="#" click="$RemoveSeat">Remove</a></td>
</tr>    
</tbody>

Суммируя:

data-bind="foreach: children"

ng-repeat="friend in friends"

$foreach(s in Seats)

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

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

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

A>>Если планируется разделение на ХТМЛ файл и прочее, то непонятно какие проблемы с "считывать и генерировать". Файл просто как ресурс идет

_NN>Будет видно что и как.
_NN>Может хотите помочь проекту ? выглядит на бумаге довольно просто для такой мегафичи

То, что я описал — это уже много где в той или иной мере реализовано и ещё один подобный фрэймворк погоды не делает.

Что было бы клёво, так это закадровая компиляция html для интеллисенса в среде.

Грубый пример

------------------------------------------------------
ApplicationFormPage.html

<html xmlns:nweb="https://github.com/NemerleWeb/NemerleWeb/"
 nweb:onrender="ApplicationFormController.render">
 <body>
  <form id="ApplicationForm" nweb:onsubmit="ApplicationFormController.submit">
   <input type="text" name="name"/>
   <input type="text" name="age"/>
   <input type="submit" />
  </form>
 </body>
</html>

------------------------------------------------------
ApplicationForm.n

class ApplicationFormController {
 public render(ApplicationFormPage page): ... {
   if (context.IsKnownUser) {
    page.ApplicationForm.Name.visible = false;
   }
 }

 public submit(ApplicationFormPage.ApplicationForm form): ... {
  ...
  form.Name
  form.Age

  ...
 }
}

Вообщем, в Немерле коде я не силен, но идея я думаю понятна. HTML компилируется на лету и создаются необходимые файлы, доступен intellisens, нельзя написать page.SearchForm, потому что такой формы нет на странице, если со страницы удаляется поле name то перестаёт компилироваться код page.ApplicationForm.Name.visible. Причем тут есть куда ещё развернуться, например указывать для формы на какой класс нужно биндить поля формы (<form id=".." nweb:bind="ApplicationModel">) и создавать этот биндинг автоматически

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

Естественно, с динамическими структурами вроде дерева, придётся усложнить.

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

<html xmlns:nweb="https://github.com/NemerleWeb/NemerleWeb/"
xmlns:nwebtree="https://github.com/NemerleWeb/NemerleWeb/Tree">
 <body>
   <div nweb:component="TreeComponent" nwebtree:level="root">
     Это корень
     <div nwebtree:node="expanded-node" nwebtree:level="1" style="font-weight:bold;color:blue;..." или class="..."> 
       Это распахнутый узел уровня 1
       <div nwebtree:node="expanded-node" nwebtree:level="2" style="font-weight:bold;color:red;..." или class="..."> 
         Это распахнутый узел уровня 2
       </div> 
       <div nwebtree:node="collapsed-node" nwebtree:level="2" style="color:green;..." или class="..."> 
         Это закрытый узел уровня 2
       </div> 
       и т.д. Если с какого-то момента стили уровней не отличаются, то nwebtree:level="2+"
     </div> 
     <div nwebtree:node="collapsed-node" nwebtree:level="1" style="color:green;..." или class="..."> 
       Это закрытый узел уровня 1
     </div> 
     
   </div>

Ну и потом по образцу, TreeComponent должен уметь превращать модель дерева в его ХТМЛ-представление. Это всё я набросал за 30 минут и скорее всего тут простор для критики, но это примерно тот веб-фрэйворк, который я мечтал бы получить (и да, он д.б. на Яве, Немерле и Сишарп — не нужны).

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

А генерировать JS обвязку, привязываться к бинам на сервере и гонять данные в обе стороны сейчас много кто умеет. Только это всё редко бывает в равной степени дружественно к паре программист/верстальщик, обычно или перекос, или тупо для обоих неудобно

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

WH>Те все твои претензии сводятся к тому, что конкретные примеры, написаны не так как тебе нравится?

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

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

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

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

M>Нет, не будет. Принципиально неверный подход. В том месте, где knockout предлагает байндинг к данным, не затрагивая основных подходов HTMLя, вы переопределяете половину аттрибутов и CSS ради чего?

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

M>Это я не говорю об абсолютно непонятном scope контрольных инструкций $when, $foreach и т.п.

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

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

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

A>>Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко.

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

А где у меня написано, что Викет умеет клиентский ЯваСкрипт? Я утверждал, что Викет идет по правильному пути с точки зрения разделения HTML и кода. ЛифтВеб умеет клиентский ЯваСкрипт и умеет разделять ХТМЛ и код, так что он дальше всех пошел. Но мне Лифт не нравится из-за своей нестройности, в него пихали всё, до чего дотянулись, получилось очень неприглядно (но концепция, заложенная в нем, мне нравится)

A>>Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф.
VD>В этом нет ничего естественного. Это — косяк.

Прочитай внимательно, я уже 2 раза писал, что это — косяк.

A>>Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм.
VD>Ты, видимо, тоже попутал какой-то шаблонный движок (которых 100500) с MVVM-фреймворком. Это как бы настолько разные вещи, что даже сравнивать их не стоит.

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

Здравствуйте, 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>Ага. Если концепции противоречат здравому смыслу, то нужно менять здравый смысл.

А где наша концепция противоречит здравому смыслу? Как раз наоборот, она отлично обоснована и выполняет свою задачу.
Она может быть непонятна для тех, кто её в первый раз видит, но это с большинством технологий так. Если человек всю жизнь программировал на ассемблере, то для него и лябмда может противоречить здравому смыслу. Что же теперь, всем под него подстраиваться?

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

I>Если кому интересно, посмотреть можно здесь: nemerlewebrsdn.apphb.com
I>Самое интересное — это код. Вся структура меню состоит из трёх Unit'ов

А как это будет выгледть ? Где можно покликать ?

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

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

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

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

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

I>>Если кому интересно, посмотреть можно здесь: nemerlewebrsdn.apphb.com

T>А как это будет выгледть ? Где можно покликать ?

Ты же сам ссылку процитировавший. Кликни по ней и покликай.

Вот еще что...

Нужна возможность получить url текущей открытой страницы (как сейчас на сайте).

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

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

У нас сейчас используется следующий метод. Если в юрле есть "?", то сайт открывает страницу вместе с деревом и делает активными все ветки указывающие на эту страницу:
http://rsdn.ru/?article/cpp/Cpp11NewStd.xml

Если же юрла вбивается без "?", то открывается страница без дерева.

Нужно поддержать данную традицию.

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

В отдельном окне тоже не открывает.

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

I>>>Если кому интересно, посмотреть можно здесь: nemerlewebrsdn.apphb.com

T>>А как это будет выгледть ? Где можно покликать ?

VD>Ты же сам ссылку процитировавший. Кликни по ней и покликай.

Эээ, я думал новое это новое, а не старое переписаное

Или предполагается сделать все тоже что есть сейчас только на другом движке ?

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

T>Эээ, я думал новое это новое, а не старое переписаное

Или предполагается сделать все тоже что есть сейчас только на другом движке ?

У нас явное недопонимание.

Новое дерево, естественно, должно воспроизводить старую функциональность. Кроме того хочется новую. Тот же поиск. Вот еще припинивание появилось.

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

    public AddPinned(id : string) : void
    {
      def pinned = nweb.getCookie("pinned");
      
      if(pinned == null) nweb.setCookie("pinned", id, 360);
      else nweb.setCookie("pinned", pinned + "," + id, 360);
      
      UpdatePinned();
    }
    
    public RemovePinned(id : string) : void
    {
      def pinned = nweb.getCookie.[string]("pinned");
      when(pinned != null) nweb.setCookie("pinned", pinned.Replace(re (",?" + id) "g", ""), 360);
      
      UpdatePinned();
    }
    
    public static GetPinned() : IEnumerable[string]
    {
      match(nweb.getCookie.[string]("pinned")) {
      | null => []
      | str => str.Split(',')
      }
    }

Вот это мне не нравится.
Нужно сделать ДСЛ для печенек.

cookie Pinned : Set[int];

А вся остальная байда должна генерироваться.
Ибо если кто-то захочет такую печеньку

cookie Pinned : Set[string];

или такую

cookie Pinned : Map[int, Set[string]];

то всё станет очень сложно.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

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

VD>1. Активная ветка не выделяется визуально. По сему невозможно понять, что сейчас открыто.
VD>2. Во вложенных элементах слишком большой отступ. Ветки уезжают вправо. Надо сделать меньших отступ.
VD>Плюсы должны начинаться сразу по окочании плюсов родительского дерева.
VD>3. Нужно показывать кнопочки для запиненых веток в дереве (не только при наведении мыши, а всегда).
Согласен.

VD>4. В окне поиска хорошо бы показывать подсказку (как в окне навигации броузера).
Watermark?

VD>5. При нажатии элемента с шифтом соответствующая страница должна открываться в отдельной закладке броузера (старая версия ведет себя именно так).
Ок, посмотрим.

VD>6. При попытке посмотреть дерево в броузере телефона, в портретном режиме размер места отводимого под дерево был столь урезан, что текст не вмещался. В альбомном (повернутом на бок) режиме тот же эффект наблюдается если открыть ветку по глубже. Нужно с этим побороться. И вообще, нужно сделать так чтобы в телефоне деревом было пользоваться так же удобно как и на компьютере.
Да, с телефоном пока проблема. Я там только ошибки рендеринга исправил, о юзабилити не думал.

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

VD>9. Вообще нет вертикального сплитера, так что изменить размеры окна не получается. В мобильном режиме сплитеры вообще не нужны. Долно показываться только дерево, а другие страницы всегда отрываться в новых закладках/окнах. Плюс размеры элементов в мобильном режиме должны быть крупнее, чтобы в них можно было попадать пальцем.
+1

VD>Вот это:
VD>

VD>    public IconUrl : string 
VD>    {      
VD>      get {        
VD>        def suffix = match(IsOpened, HasChildren) {
VD>                      | (false, true) => "c.gif" 
VD>                      | (true, _) => "o.gif";
VD>                      | _ => "s.gif";
VD>                     };
VD>        "http://rsdn.ru/images/tree/" + Icon + suffix;
VD>      }
VD>    }
VD>

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

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

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

VD>У нас сейчас используется следующий метод. Если в юрле есть "?", то сайт открывает страницу вместе с деревом и делает активными все ветки указывающие на эту страницу:
http://rsdn.ru/?article/cpp/Cpp11NewStd.xml
ОК, посмотрим.

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

WH>Нужно сделать ДСЛ для печенек.
Согласен, DSL пригодится.

WH>

WH>cookie Pinned : Set[int];
WH>

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

WH>Ну и необходимость везде писать UpdatePinned тоже плохо. Система должна сама реагировать на изменение печеньки.
В принципе, если у нас код наподобие такого:

ValueInCookies : string { get { //read value from cookies } }
   
Method() : void {
   "Hello, " + ValueInCookies;
}

То работать будет и сейчас.
У нас по-любому сейчас нет выборочного биндинга. На любое изменение все биндинги пересчитываются заново.

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

I>Тут надо определится с коллекциями, которые можно будет сериализовывать. Далеко не все .NET контейнеры для этого подходят.
Set, MultiSet, Dictionary, MultiDictionary и List.
Этого думаю хватит.

I>У нас по-любому сейчас нет выборочного биндинга. На любое изменение все биндинги пересчитываются заново.
Это плохо. До релиза нужно исправить.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

I>>У нас по-любому сейчас нет выборочного биндинга. На любое изменение все биндинги пересчитываются заново.
WH>Это плохо. До релиза нужно исправить.

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

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

VD>>4. В окне поиска хорошо бы показывать подсказку (как в окне навигации броузера).
I>Watermark?

Нет. Выпадающий список с вариантами.

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

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

В понедельник постучись на скайп — сделаем.

VD>>

VD>>                      | (false, true) => "c.gif" 
VD>>                      | (true, _) => "o.gif";
VD>>                      | _ => "s.gif";
VD>>                     };
VD>>        "http://rsdn.ru/images/tree/" + Icon + suffix;
VD>>

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

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

VD>>Изначально я предлагал сделать возможность поиска по подветкам. Хорошо бы придумать что-нибудь вроде этого. Тогда можно было бы искать ".Net" только среди форумов, что облегчило бы поиск именно форумов.
I>Поиск по подветкам неудобен, т.к. результаты поиска могут находится на много уровней ниже и раскиданы по разным частям дерева. Добраться до них всех, будет нетривиальным занятием.

Попробуй найти форум по .Net или Nemerle. Тебе будет выдано туева хуча веток где встречается .Net или Nemerle. Найти нужный элемент очень сложно. Если же искать только по форумам, то найти будет элементарно (форумов по .Net — три, а по Nemerle — два.

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

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

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

Мне кажется будет лучшим решением добавить категории как в поиске гугла.
Скажем: Все | Форумы | Статьи

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

_NN>Мне кажется будет лучшим решением добавить категории как в поиске гугла.
_NN>Скажем: Все | Форумы | Статьи

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

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

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

_NN>>Мне кажется будет лучшим решением добавить категории как в поиске гугла.
_NN>>Скажем: Все | Форумы | Статьи

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

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

А так вбил в поиск, не нашлось с первого раза, выбрал категорию и нашел.

При подведении указателя к иконке пина она исчезает.
Opera 12.02.

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

W>При подведении указателя к иконке пина она исчезает.
W>Opera 12.02.

Оперу еще никто не проверял.

Может знаете в чем причина ? Скорее всего там стиль нужно подправить и оно заработает.

P.S.
Ждем Оперу на WebKit

_NN>Оперу еще никто не проверял.

_NN>Может знаете в чем причина ? Скорее всего там стиль нужно подправить и оно заработает.

.node .node-caption {
display: block;
margin-left: 35px;
margin-right: 26px;
}

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

А>Можно заменить на

А>

А>padding-right: 26 px;

А>В этом случае это будет внутренний отступ от границы и это пространство будет принадлежать элементу node-caption и ховер будет работать.

Проблему решило.
Спасибо

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

_NN>Мне кажется будет лучшим решением добавить категории как в поиске гугла.
_NN>Скажем: Все | Форумы | Статьи

А мне кажется, что надо просто выдавать в поиске форумы первыми, как-то так:

.NET — Форум
.NET GUI — Форум
ASP.NET — Форум
Хеширование, шифрование и цифровая подпись с использованием CryptoAPI и .Net CLR

Ну и иконками выделить.

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

VD>1. Активная ветка не выделяется визуально. По сему невозможно понять, что сейчас открыто.
VD>2. Во вложенных элементах слишком большой отступ. Ветки уезжают вправо. Надо сделать меньших отступ. Плюсы должны начинаться сразу по окочании плюсов родительского дерева.
VD>3. Нужно показывать кнопочки для запиненых веток в дереве (не только при наведении мыши, а всегда).
VD>4. В окне поиска хорошо бы показывать подсказку (как в окне навигации броузера).
VD>5. При нажатии элемента с шифтом соответствующая страница должна открываться в отдельной закладке броузера (старая версия ведет себя именно так).
VD>6. При попытке посмотреть дерево в броузере телефона, в портретном режиме размер места отводимого под дерево был столь урезан, что текст не вмещался. В альбомном (повернутом на бок) режиме тот же эффект наблюдается если открыть ветку по глубже. Нужно с этим побороться. И вообще, нужно сделать так чтобы в телефоне деревом было пользоваться так же удобно как и на компьютере.
VD>7. Цвета не очень. Но это уже фигня.
VD>8. Настройки нужно хранить не в куках, а не сервере. Это не дело когда на каждом девайсе нужно настраивать окружение. Доложно быть так — залогинился и работаешь со своим окружением на любом машине в любом броузере.
VD>9. Вообще нет вертикального сплитера, так что изменить размеры окна не получается. В мобильном режиме сплитеры вообще не нужны. Долно показываться только дерево, а другие страницы всегда отрываться в новых закладках/окнах. Плюс размеры элементов в мобильном режиме должны быть крупнее, чтобы в них можно было попадать пальцем.

1, 2, 3, 5 (только не с шифтом, а с контролом), 9 (сплиттер) — сделал.

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

VD>>4. В окне поиска хорошо бы показывать подсказку (как в окне навигации броузера).
VD>>5. При нажатии элемента с шифтом соответствующая страница должна открываться в отдельной закладке броузера (старая версия ведет себя именно так).
VD>>6. При попытке посмотреть дерево в броузере телефона, в портретном режиме размер места отводимого под дерево был столь урезан, что текст не вмещался. В альбомном (повернутом на бок) режиме тот же эффект наблюдается если открыть ветку по глубже. Нужно с этим побороться. И вообще, нужно сделать так чтобы в телефоне деревом было пользоваться так же удобно как и на компьютере.
VD>>7. Цвета не очень. Но это уже фигня.
VD>>8. Настройки нужно хранить не в куках, а не сервере. Это не дело когда на каждом девайсе нужно настраивать окружение. Доложно быть так — залогинился и работаешь со своим окружением на любом машине в любом броузере.
VD>>9. Вообще нет вертикального сплитера, так что изменить размеры окна не получается. В мобильном режиме сплитеры вообще не нужны. Долно показываться только дерево, а другие страницы всегда отрываться в новых закладках/окнах. Плюс размеры элементов в мобильном режиме должны быть крупнее, чтобы в них можно было попадать пальцем.

I>1, 2, 3, 5 (только не с шифтом, а с контролом), 9 (сплиттер) — сделал.

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

Сплитер хороший. Но его нужно бы покрасить в голубенкий (как сейчас на сайте).

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

С мобильником стало получше, но проблемы не исчезли. Все же нужно определять, что броузер мобильный и выдавать только одно дерево. Кроме того нужно увеличить размеры элементов в мобильной версии. Сейчас попасть в них не просто даже на моей лопате (Samsung Galaxy Note 2).

С кнопками и пришпиливанием тоже не все хорошо. Попасть в них сложно (но это решится, если увеличить размер элемента). Причем даже попав поведение несколько странное. Не понятно пришпилилась ветка или нет. Анимация видимо запаздывает.

Стукнись мне в скайп. Создам тебе экаунт и попробуешь на РСДН все это дело запустить (через терминалку).

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

Господа старперы (не сочтите за оскорбление), за последние 5 лет стали популярны устройства, в народе называемые планшетами. Представьте, это такая штука, как ноутбук у которого оторвали клавиатуру.
Эти устройства, как правило, не очень большого размера. Тыкают в них пальцем. И, напоминаю, основная аудитория рсдн-а мужики, соответственно, пальцы у них довольно крупного размера.

В связи с вышесказаным, прошу принять следующие меры:
— увеличить иконку [+],
— увеличить расстояние между строками
— немного отодвинуть иконки [+] от края экрана

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

D>- увеличить расстояние между строками
Тут компромисс между количеством помещающихся на том же планшете/телефоне строк и удобством тыкания. Можно будет ещё подрегулировать.

D>- немного отодвинуть иконки [+] от края экрана

Тыкать, кстати, можно не только в "+", но и в саму надпись. То, что на самом РСДН это пока не так, имхо, очень неправильно.

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

D>>- увеличить расстояние между строками
I>Тут компромисс между количеством помещающихся на том же планшете/телефоне строк и удобством тыкания. Можно будет ещё подрегулировать.

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

Тогда можно будет нажать на экран и протащить палец вверх/вниз/вправо/влево чтобы выбрать именно то элемент что нужен (в том числе осуществить выбор между плюсом, телом и пином).

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

D>Господа старперы (не сочтите за оскорбление),

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

D>за последние 5 лет стали популярны устройства, в народе называемые планшетами.

"Старперы" как бэ в крусе. Более того активно пользуются оными девайсами, да и смартфонами.

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

D>В связи с вышесказаным, прошу принять следующие меры:
D>- увеличить иконку [+],
D>- увеличить расстояние между строками
D>- немного отодвинуть иконки [+] от края экрана

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

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

I>Тыкать, кстати, можно не только в "+", но и в саму надпись. То, что на самом РСДН это пока не так, имхо, очень неправильно.

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

По сему просто делать тело аналогом нажатие на плюс нельзя.

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

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

VD>Тут важен компромис между удобством попадания и объемом отображаемых на девайсе данных. В конце концов хочется иметь возможность посещать РСДН и со смартфонов. Мой, правда, тянет на маленький планшет. Но есть люди и с Айфонами.
Данные можно проскроллить. А вот попадать пальцем в иконку на миллиписичном экране айфона, наверно, то еще удовольствие.

Пользуясь случаем хочу сделать еще рацпредложения.

Цифры с номерами страниц прилеплены к самому низу экрана и расстояние между ними тоже маленькое. Можно их чуть преподнять и расстояние между ними чуть увеличить?
И, самое главное. На планшете в ландшафтном режиме невозможно написать сообщение, т.к. когда появляется экранная клавиатура, поле ввода текста схлопывается до 5px в высоту. Для решения этой проблемы достаточно выставить min-height у поля ввода текста. Проблема решается за 2 минуты, я об этом писал в другой теме, но воз и ныне там.

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

D>Цифры с номерами страниц прилеплены к самому низу экрана и расстояние между ними тоже маленькое. Можно их чуть преподнять и расстояние между ними чуть увеличить?

Что за номера страниц? О чем речь?

D>И, самое главное. На планшете в ландшафтном режиме невозможно написать сообщение, т.к. когда появляется экранная клавиатура, поле ввода текста схлопывается до 5px в высоту. Для решения этой проблемы достаточно выставить min-height у поля ввода текста. Проблема решается за 2 минуты, я об этом писал в другой теме, но воз и ныне там.

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

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

VD>Здравствуйте, Dolios, Вы писали:
D>>Цифры с номерами страниц прилеплены к самому низу экрана и расстояние между ними тоже маленькое. Можно их чуть преподнять и расстояние между ними чуть увеличить?
VD>Что за номера страниц? О чем речь?
Топик когда читаешь, если сообщений много, они показываются на нескольких страницах, вот внизу номера этих самых страниц и выводятся

D>>И, самое главное. На планшете в ландшафтном режиме невозможно написать сообщение, т.к. когда появляется экранная клавиатура, поле ввода текста схлопывается до 5px в высоту. Для решения этой проблемы достаточно выставить min-height у поля ввода текста. Проблема решается за 2 минуты, я об этом писал в другой теме, но воз и ныне там.
VD>Мы здесь обсуждаем только дерево. Закончим с деревом, можно будет поговорить и о остальных частях сайта.
Да я не против, просто баг фиксится за 2 минуты, но жутко раздражает. Я в другой теме это уже писал, но никто не отреагировал. Может тут кто прочитает и запомнит, что есть такая проблема. Хотя, почему бы ее сразу не исправить, я не понимаю.

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

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

VD>Тогда можно будет нажать на экран и протащить палец вверх/вниз/вправо/влево чтобы выбрать именно то элемент что нужен (в том числе осуществить выбор между плюсом, телом и пином).

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

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

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

I>>Тыкать, кстати, можно не только в "+", но и в саму надпись. То, что на самом РСДН это пока не так, имхо, очень неправильно.

VD>Сначала было огласился. Но потом понял, что все не так просто. Дело в том, что у нас на узловых ветках дерева вешается разного рода агрегированная информация. Ну, там список статей с аннотациями (что не влезет в дерево) и т.п.

VD>По сему просто делать тело аналогом нажатие на плюс нельзя.

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

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

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

Согласен. Но это должно быть открытие контента, а не раскрытие ветки.

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

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

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

VD>В принципе если сделать вывод аннотаций хинтом в дереве
Хинт по mouseover имеется в виду?

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

I>Не уверен, что это будет очевидный для пользователей UI, но попробовать можно.

Дык тут только путем проб и ошибок и можно найти хорошее решение.

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

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

Это в плоском режиме? Да, там ссылки мелковаты.

А кто-нибудь пробовал эту радость на мобильном устройстве открыть? На iOS есть дерево, форума нет, что на мой взгляд не правильно.

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

KP>А кто-нибудь пробовал эту радость на мобильном устройстве открыть? На iOS есть дерево, форума нет, что на мой взгляд не правильно.
Форум то как раз открывается (справа видно немного его), но вот сплиттер не дает двигать экран.
Кто силен в html-е и готов выделить время на фикс, милости просим.

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

KP>А кто-нибудь пробовал эту радость на мобильном устройстве открыть? На iOS есть дерево, форума нет, что на мой взгляд не правильно.

Для мобильников уже всё продумано, но ничего не сделано

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

 public View() : string
    {
      <#
        <div class="page">
          <div class="left">          
            <div $when(Root != null) class="root">
              <div template="$(template(Search))" />
              <div $when(string.IsNullOrEmpty(Search.SearchTerm))>
....

Дизайнеру не отдать, без перекомпиляции не изменить

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

M>Дизайнеру не отдать, без перекомпиляции не изменить

Ну это можно сказать тогда и про Spark:

<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
  <li each="var p in products">${p.Name}</li>
</ul>
<else>
  <p>No products available</p>
</else>

И про Razor:

<ul>
@for (int i = 0; i < 10; i++) {
<li>@i</li>
}
</ul>

Приветствуется конструктивная критика.
Предлагайте как улучшить.

M>>Дизайнеру не отдать, без перекомпиляции не изменить

_NN>Ну это можно сказать тогда и про Spark:
_NN>И про Razor:
_NN>

И про стопятьсот других таких же подходов. От того, что кто-то так делает, это не становится правильным или удобным

_NN>Приветствуется конструктивная критика.
_NN>Предлагайте как улучшить.

Вынести в отдельные текстовые файлы. С возможности перезагрузки/перекомпиляции на лету.

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

_NN>>Приветствуется конструктивная критика.
_NN>>Предлагайте как улучшить.

M>Вынести в отдельные текстовые файлы. С возможности перезагрузки/перекомпиляции на лету.

Можно подробней ?
Каким образом это поможет "отдать дизайнеру" ?

M>>Вынести в отдельные текстовые файлы. С возможности перезагрузки/перекомпиляции на лету.

_NN>Можно подробней ?
_NN>Каким образом это поможет "отдать дизайнеру" ?

Имел в виду верстальщику, скорее, чем дизайнеру.

В частности, поможет тем, что не надо будет смотреть на абсолютно ненужный ему код на Nemerle, и не надо будет знать абсолютно ненужные ему вещи типа «скомпиль и задеплой на сервер»

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

M>>>Вынести в отдельные текстовые файлы. С возможности перезагрузки/перекомпиляции на лету.

_NN>>Можно подробней ?
_NN>>Каким образом это поможет "отдать дизайнеру" ?

M>Имел в виду верстальщику, скорее, чем дизайнеру.

M>В частности, поможет тем, что не надо будет смотреть на абсолютно ненужный ему код на Nemerle, и не надо будет знать абсолютно ненужные ему вещи типа «скомпиль и задеплой на сервер»
Примеры в студию.
Где тогда писать этот "ненужный код" ?

Автоматической компиляции с изменениями добиться можно относительно просто EasyMVC .
Но без деплоя на сервер как это должно работать ?

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

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

M>>>В частности, поможет тем, что не надо будет смотреть на абсолютно ненужный ему код на Nemerle, и не надо будет знать абсолютно ненужные ему вещи типа «скомпиль и задеплой на сервер»
_NN>>Примеры в студию.
_NN>>Где тогда писать этот "ненужный код" ?

M>О боже. Любой шаблонный движок в руки.
Короче, вам не нравится , что View не в отдельном файле.

M>С точки зрения верстальщика (да и любого человека, занимающегося сайтом) это должно выглядеть так:
M>— запустил сервер локально
M>— изменил шаблон, сохранил
M>— нажал F5 в браузере — изменения появились.
Ну это можно делать компиляций на лету при изменении файлов.
Я уже давал ссылку на проект, который это позволяет сделать.

Нет никаких принципиальных проблем вытащить тело метода View в отдельный файл.
Это не сделано сейчас из соображений простоты.
Можно сделать хоть сейчас, макрос прочитает файл, скажем Page_View.htmln , а если файл не найден, то будет искать метод View.
Поможете проекту и будет отдельно

M>>О боже. Любой шаблонный движок в руки.
_NN>Короче, вам не нравится , что View не в отдельном файле.

Короче, мне не нравится, когда код логики и html в одном файле «потому что есть два проекта, где сделано так же»

_NN>Нет никаких принципиальных проблем вытащить тело метода View в отдельный файл.
_NN>Это не сделано сейчас из соображений простоты.
_NN>Можно сделать хоть сейчас, макрос прочитает файл, скажем Page_View.htmln , а если файл не найден, то будет искать метод View.

Не только можно, но и нужно.

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

M>Не только можно, но и нужно.

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

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

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

_NN>Можно сделать хоть сейчас, макрос прочитает файл, скажем Page_View.htmln , а если файл не найден, то будет искать метод View.

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

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

Кстати, это не всегда то что нужно. Иногда нужно генерировать плоский HTML на сервере. Было бы здорово, если бы сделали поддержку рендеренга на сервере. А то для странички загрузки немерловых сборок Хардкйс взял Разор просто потому что плоскую страничку лучше будут индексировать поисковики.

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

M>Короче, мне не нравится, когда код логики и html в одном файле «потому что есть два проекта, где сделано так же»

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

Сравнивать это с движками рендеренга html-я все равно что сравнивать печать на принтер с GUI на дисплее.

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

VD>Кстати, это не всегда то что нужно. Иногда нужно генерировать плоский HTML на сервере. Было бы здорово, если бы сделали поддержку рендеренга на сервере. А то для странички загрузки немерловых сборок Хардкйс взял Разор просто потому что плоскую страничку лучше будут индексировать поисковики.
Одно не отменяет другое.
Никто не запрещает совмещать статические страницы на Razor MVC с динамическими NemerleWeb MVVM.

M>>Короче, мне не нравится, когда код логики и html в одном файле «потому что есть два проекта, где сделано так же»

VD>Ты упускаешь одну очень важную деталь. Это не html — это код логики представления.

Да-да-да. вот эти все div'ы и прочий HTML — это не HTML, ты чо. Это — код логики представления, ага.

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

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

VD>Сравнивать это с движками рендеренга html-я все равно что сравнивать печать на принтер с GUI на дисплее.

Я где-то говорю про рендеринг html? Да нигде.

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

В каком месте это не шаблонный движок?

VD>а MVVM-фрэймворк цель которого создавать интерактивный UI.

Каким образом ты его собрался создавать, если у тебя там банальный захардкоженный HTML?

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

M>В каком месте это не шаблонный движок?

В любом.

VD>>а MVVM-фрэймворк цель которого создавать интерактивный UI.

M>Каким образом ты его собрался создавать, если у тебя там банальный захардкоженный HTML?

Он уже создан (не мной, правда). Разберись в том что обсуждаешь.

VD>>>а MVVM-фрэймворк цель которого создавать интерактивный UI.

M>>Каким образом ты его собрался создавать, если у тебя там банальный захардкоженный HTML?

VD>Он уже создан (не мной, правда). Разберись в том что обсуждаешь.

А что там обсуждать:

[Unit]
public class SamplePage
{
  public Name : string;

  [Html]
  public View() : string
  {
     <#
       <input value="$Name" />
       <div>Hello, $Name</div>
     #>
  }
}

How will our main code change? Actually not that much:

Tasks : List[Task] = List[Task]();
TaskToAdd : Task = Task("", 0, false);

AddTask() : void
{
  Tasks.Add(TaskToAdd);
  TaskToAdd = Task("", 0, false);
}

[Html]
View() : string
{
  <#
    <input value="$TaskToAdd.Title" />
    <input value="$TaskToAdd.Priority" />
    <button click="$AddTask" />
    <ul $foreach(t in Tasks.OrderBy(t => t.Priority))>
      <li>
   $(t.Priority): $(t.Title)
   <input type="checkbox" checked="$(t.Status)" />
      </li>
    </ul>
  #>

}

Нет, ты что. HTML, пишущийся ручаками, который надо менять на каждый чих, — это не шаблоны, ты что! Это, что ни на есть самое динамическое из динамических UI!

Лучше бы ты Влад, разобрался, в том, что в Вебе уже есть, а не становился грудью защищать баррикады. Это — банальные шаблоны. На том же DTL (Django Template Language) деревья делаются практически один-в-один точно таким же кодом: http://stackoverflow.com/a/11644588/445049

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

_NN>Никто не запрещает совмещать статические страницы на Razor MVC с динамическими NemerleWeb MVVM.

Для разора не нужен ни Немерл, ни NemerleWeb. А вот использовать две нотации как-то совсем не здорово. Оптимально было бы иметь возможность использовать NemerleWeb и как статический серверный рендерер.

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

M>В каком месте это не шаблонный движок?

В месте биндинка.

VD>>а MVVM-фрэймворк цель которого создавать интерактивный UI.

M>Каким образом ты его собрался создавать, если у тебя там банальный захардкоженный HTML?

Еще раз советую разобраться в вопросе. Кури MVVM.

M>>В каком месте это не шаблонный движок?
VD>В месте биндинка.

Что есть binding с твоей точки зрения?

Умение делать {{имя переменной}} посередине HTMLя?

VD>>>а MVVM-фрэймворк цель которого создавать интерактивный UI.

M>>Каким образом ты его собрался создавать, если у тебя там банальный захардкоженный HTML?

VD>Еще раз советую разобраться в вопросе. Кури MVVM.

«Уж послала так послала» ©

То, что у вас MVVM никак не отменяет того факта, что это — захардкоженный HTML, который еще верстать надо. От того, что вы к нему приклеили foreach, возможности вызова Nemerle-кода и кой-какую генерацию JS, никак не отменяет того факта, что это — захардкоженный HTML, требующий верстки и изменения на каждый мало-мальский чих.

Даже в мега-документе, в котором я «должен был разобраться прежде чем», полностью состоит из «если мы хотим что-то сделать, пишем хардкодный HTML», «если хотим что-то изменить, делаем хардкодный HTML»

Если ты так уверен, что это все неправда, приведи мне конкретный пример, который отличает ваш шаблонный движок от двух сотен других, таких же.

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

M>То, что у вас MVVM никак не отменяет того факта, что это — захардкоженный HTML, который еще верстать надо. От того, что вы к нему приклеили foreach, возможности вызова Nemerle-кода и кой-какую генерацию JS, никак не отменяет того факта, что это — захардкоженный HTML, требующий верстки и изменения на каждый мало-мальский чих.
Кстати, а кто ещё умеет немножко генерить JS? Ну GWT не берём — я его ниасиливаю.

M>>То, что у вас MVVM никак не отменяет того факта, что это — захардкоженный HTML, который еще верстать надо. От того, что вы к нему приклеили foreach, возможности вызова Nemerle-кода и кой-какую генерацию JS, никак не отменяет того факта, что это — захардкоженный HTML, требующий верстки и изменения на каждый мало-мальский чих.
F> Кстати, а кто ещё умеет немножко генерить JS? Ну GWT не берём — я его ниасиливаю.

Они его не столько и не только генерят, сколько вызывают колбэки на сервере, из примеров.

Честно скажу, что у кого-то видел, но у кого — не помню. Движков много, а меня мало

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

M>>>В каком месте это не шаблонный движок?
VD>>В месте биндинка.

M>Что есть binding с твоей точки зрения?
M>Умение делать {{имя переменной}} посередине HTMLя?

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

Нет. Биндинг это связывание некоторых свойств, полей или структур данных с элементами UI. Связь может быть односторонней или двусторонней. Скажем если ты связал свойство user.Name с <input value="$(user.Name)" />, то при изменении поля ввода будет меняться свойство (вызваться его сетер) и наоборот.

Это нечто вроде контролов в GUI, а не тупая печать в файл. UI получается интерактивным. Это накладывает некоторые ограничения на процесс верстки. Отдавать разработку таких вьюх дизайнерам имеет мыло смысла. Им лучше отдавать настройку css-а, с помощью которого они смогут управлять внешним видом UI. Ну, и шаблонов которые определяют относительно большие объемы статического ХТМЛ-я. А вьюхи что ты видишь в функциях View слишком мелкие и слишком перенасыщенные логикой представления, чтобы не программист мог эффективно с ними взаимодействовать, на мой взгляд.

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

M>То, что у вас MVVM никак не отменяет того факта, что это — захардкоженный HTML, который еще верстать надо. От того, что вы к нему приклеили foreach, возможности вызова Nemerle-кода и кой-какую генерацию JS, никак не отменяет того факта, что это — захардкоженный HTML, требующий верстки и изменения на каждый мало-мальский чих.

То что у них (я тут никаким боком) MVVM меняет очень многое. Главное что меняется подход к построению сайта. Он становится интерактивным, а вот простыней с относительно статическим ХТМЛ-ем становится меньше.

M>Если ты так уверен, что это все неправда, приведи мне конкретный пример, который отличает ваш шаблонный движок от двух сотен других, таких же.

Давай сделаем просто. Ты найдешь шаблонный движок средствами которого сделано дерево аналогичное сабжевому. Когда ты задолбаешся искать, то поймешь, что шаблонные движки попросту на это не рассчитаны. Потом попробуй найти реализацию дерева на JS или любом другом языке программирования. Вглядись в код и пойми, что то что в приведенной реализации находится в том что ты называешь шаблоном в найденной тобой реализации (если, конечно это не MVVM-реализация на базе какого-нить НокаутаЖС) будет тупо разбросанно в виде строковых литералов в куче жудчайшего императивного кода реагирующего на события и вручную модифицирующего DOM.

Никакому верстальщику ты этот код отдать не сможешь просто потому, что это код! Заслуга авторов NemerleWeb заключается как раз в том, что они смогли сделать так, чтобы вместо гор плохо читаемого кода создавался бы простой и ясный код модели + коротенькие представление использующие парадигму биндинга для отображения данных очень шаблонную систему для динамического рендеренга ХТМЛ-я.

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

M> public View() : string
M> {
M> <#
M> <div class="page">

M>Дизайнеру не отдать, без перекомпиляции не изменить

Я согласен с Мамутом, что бы это ни было (никто тут объяснять технические термины доступно не умеет), если на выходе это будет HTML, это ОБЯЗАН делать хтмл-верстальщик. Своим любимым инструментом, в котором синтаксис движка не интерферирует с синтаксисом HTML. В идеале — исполняемый код держать в спец-комментах  , а подстановку переменных — видимой, типа <div>[$myvar]</div>
Если бóльшую часть логики вынести во всякие функции, на долю шаблона придутся совсем небольшие проверки типа  ...
Хотя... может я не уловил суть спора?

M>>Если ты так уверен, что это все неправда, приведи мне конкретный пример, который отличает ваш шаблонный движок от двух сотен других, таких же.

VD>Давай сделаем просто.

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

VD>(если, конечно это не MVVM-реализация на базе какого-нить НокаутаЖС)

Ну да, действительно. Главное ведь что? ПОставить идиотские требования

VD>Никакому верстальщику ты этот код отдать не сможешь просто потому, что это код!

О да. Весь этот нагенеренный кривыми ручками программистов код САМ сложится в красивую страничку, ага-ага.

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

Пока что всю «заслугу» я вижу в том, что для малейших изменений надо лопатить HTML. Любой залетный незакрытый <div> сломает любой сайт к чертям. Но да, я помню. Верстальщики не нужны!

Здравствуйте, Ziaw, Вы писали:
Z>А мне кажется, что надо просто выдавать в поиске форумы первыми, как-то так:

Z>.NET — Форум
Z>.NET GUI — Форум
Z>ASP.NET — Форум
Z>Хеширование, шифрование и цифровая подпись с использованием CryptoAPI и .Net CLR

Тут проблема в том, что сейчас ищется только подстрока (а не шаблон). А стало быть отфильтровать по " — Форум" будет не просто, так как придется писать окончание имени форума. Для ".NET GUI — Форум" оно может и не сложно. Но для форумов с длинными именами будет не так удобно.

Тут нужно или вделать более сложный поиск (например, ищущий вхождение нескольких слов, если они разделены пробелами: ".NE Фор" найдет все форумы по дотнету), или дать таки возможность задать тип разыскиваемого контента.

"Строка " — Форум" в именах всех форумов будет смотреться не очень красиво. Дерево будет удлинняться. К статьям так же придется дописывать " — Статья".

Я вот подумал, что можно поступить следующим образом — выводить список всех вхождений, как сейчас, но кроме того, перед списком, выводить набор кнопок-тегов (по одной для каждого типа веток). Тогда для подстроки ".NET" будет выдан набор кнопок:

[ Все ][ Статьи ][ Форумы ][ Файлы ][ Проекты ]

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

Z>Ну и иконками выделить.

Это уже есть. Но по ним не поищешь.

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

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

_NN>>Никто не запрещает совмещать статические страницы на Razor MVC с динамическими NemerleWeb MVVM.

VD>Для разора не нужен ни Немерл, ни NemerleWeb. А вот использовать две нотации как-то совсем не здорово. Оптимально было бы иметь возможность использовать NemerleWeb и как статический серверный рендерер.

Я понимаю просто иметь спец. атрибут, чтобы не генерировать биндинги и вставить "как есть" ?
Этого достаточно ?

[StaticHtml]
public View() : string
{ 
 <# ... #>
}

В таком случае конечно удобней если это будет в отдельном файле.

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

VD>Тут проблема в том, что сейчас ищется только подстрока (а не шаблон). А стало быть отфильтровать по " — Форум" будет не просто, так как придется писать окончание имени форума. Для ".NET GUI — Форум" оно может и не сложно. Но для форумов с длинными именами будет не так удобно.

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

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

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

M>Короче, мне не нравится, когда код логики и html в одном файле «потому что есть два проекта, где сделано так же»
M>Не только можно, но и нужно.

Ок.
Допустим у нас отдельный файл.

Наверстали тут страницу:

<div>Hello</div>
<div>World</div>

А теперь хотим добавить логику.
Где ее добавлять если том же файле плохо , ведь тогда это мешает верстальщику

<div>Hello</div>
<div visible="$SomeVar">World</div>

Ну и получается что меняем "код" каждый раз когда меняем логику.
Или как-то выносить логику изменений из html-я , но куда и как ?

Или по вашему текст в html файле не считается кодом ?

_NN>Наверстали тут страницу:
_NN>

_NN><div>Hello</div>
_NN><div>World</div>
_NN>

_NN>А теперь хотим добавить логику.
_NN>Где ее добавлять если том же файле плохо , ведь тогда это мешает верстальщику

Это уже меньше мешает верстальщику. Более того, верстальщик может менять дизайн/верстку, не ожидая, пока это сподобится за него сделать программист.

_NN>

_NN><div>Hello</div>
_NN><div visible="$SomeVar">World</div>
_NN>

_NN>Ну и получается что меняем "код" каждый раз когда меняем логику.
_NN>Или как-то выносить логику изменений из html-я , но куда и как ?

_NN>Или по вашему текст в html файле не считается кодом ?

Я имел в виду, что, по сути, для каждого телодвижения надо привлекать программиста, чтобы он правил HTML-код. Тебе не кажется, что HTML-код должен править верстальщик?

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

M>Блин. Еще один. Тебе провести урок HTML 101, рассказывающий, как и каким образом можно порушить любую верстку совершенно валидным маркапом?
Мамут такой мамут.
Вместо того чтобы признать что из-за незнания сморозил глупость начал дальше вертеться.
А то, что можно написать код, который делает не то что нужно в этом никто не сомневается.

WH>>Ну и попробуй понять разницу между серверным шаблонным движком коих тьма.
WH>>И клиентским MVVM которым является Nemerle.Web.
M>Ты можешь повторять эту мантру сколько угодно. Но до тех пор пока для малейших изменений необходимо, чтобы программист правил HTML-код, движок можно закапывать.
Покажи мне движок, который может то же самое что и Nemerle.Web и там не нужно править код.
Вот, например http://learn.knockoutjs.com/#/?tutorial=intro
Там тоже приходится код внутри HTML писать.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

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

M>Это уже меньше мешает верстальщику. Более того, верстальщик может менять дизайн/верстку, не ожидая, пока это сподобится за него сделать программист.
M>Я имел в виду, что, по сути, для каждого телодвижения надо привлекать программиста, чтобы он правил HTML-код. Тебе не кажется, что HTML-код должен править верстальщик?

Не совсем понимаю.
У нас есть логика представления, скажем, показывать или не показывать <div>.
Это зависит от какой-нибудь переменной , скажем X.
Завтра она меняется на Y или ну другую логику, и "надо привлекать программиста".

Давай более развернутый пример.
Что было, как мы хотим это изменить, и каким образом не нужен программист.

M>>Блин. Еще один. Тебе провести урок HTML 101, рассказывающий, как и каким образом можно порушить любую верстку совершенно валидным маркапом?
WH>Мамут такой мамут.
WH>Вместо того чтобы признать что из-за незнания сморозил глупость начал дальше вертеться.

Вертишься тут только ты с Владом

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

Угу. Когда программисты, никогда ничего не делавшие внятного для веба, начинают рассказывать «а, ничего, потом дизайнеры CSS-ом подправят», таких программистов надо отправлять пилить что-нибудь другое, а не веб.

WH>>>Ну и попробуй понять разницу между серверным шаблонным движком коих тьма.
WH>>>И клиентским MVVM которым является Nemerle.Web.
M>>Ты можешь повторять эту мантру сколько угодно. Но до тех пор пока для малейших изменений необходимо, чтобы программист правил HTML-код, движок можно закапывать.
WH>Покажи мне движок, который может то же самое что и Nemerle.Web и там не нужно править код.
WH>Вот, например http://learn.knockoutjs.com/#/?tutorial=intro
WH>Там тоже приходится код внутри HTML писать.

«Внутри» надо писать два с половиной байндинга, а не говнокодить захардкоженный HTML внутри кода приложения.

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

Зачем дизайнеру ставить студию и компилировать эти исходники? Более того, еще и разбираться в Немерле-коде, чтобы что-то не напортачить?

Самый простейший пример я уже привел. Заменить отображение «ищется» на спиннер внутри поискового поля или на самой кнопке. Покажи, как это будет сделано на мега-вебфреймворке, который «ах-ах-ах является способом создания динамического GUI».

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

M>«Внутри» надо писать два с половиной байндинга, а не говнокодить захардкоженный HTML внутри кода приложения.
Понятно. Писать код на жабоскрипте дизайнерам можно.
На немерле нет.
Я тебя правильно понял?

M>Зачем дизайнеру ставить студию и компилировать эти исходники? Более того, еще и разбираться в Немерле-коде, чтобы что-то не напортачить?
А зачем дизайнеру ставить knockoutjs, разбираться в коде на жабоскрипте чтобы что-то не напортачить?

M>Самый простейший пример я уже привел. Заменить отображение «ищется» на спиннер внутри поискового поля или на самой кнопке. Покажи, как это будет сделано на мега-вебфреймворке, который «ах-ах-ах является способом создания динамического GUI».
Примерно так же как на knockoutjs.
Только код будет намного чище. Без всякого уродства типа ko.observable. И компилятор проследит, что все закрывающие теги на месте и нет опечаток в биндингах.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

M>>«Внутри» надо писать два с половиной байндинга, а не говнокодить захардкоженный HTML внутри кода приложения.
WH>Понятно. Писать код на жабоскрипте дизайнерам можно.
WH>На немерле нет.
WH>Я тебя правильно понял?

Нет, неправильно. Максимум, что надо выучить — язык шаблона и пару специфических аттрибутов типа data-bind

M>>Зачем дизайнеру ставить студию и компилировать эти исходники? Более того, еще и разбираться в Немерле-коде, чтобы что-то не напортачить?
WH>А зачем дизайнеру ставить knockoutjs, разбираться в коде на жабоскрипте чтобы что-то не напортачить?

Ему его не надо ставить, и разбираться в коде яваскрипта не надо.

M>>Самый простейший пример я уже привел. Заменить отображение «ищется» на спиннер внутри поискового поля или на самой кнопке. Покажи, как это будет сделано на мега-вебфреймворке, который «ах-ах-ах является способом создания динамического GUI».
WH>Примерно так же как на knockoutjs.
WH>Только код будет намного чище. Без всякого уродства типа ko.observable. И компилятор проследит, что все закрывающие теги на месте и нет опечаток в биндингах.

Да-да. Будет только захардкоженый HTML, который будет править программист, ага

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

Что такое меняем код ?
Мы говорим про текст метода 'View' ?

Скажем вот:

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

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

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

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

A>Для этого нужен программист, а для правки ХТМЛ и стилей нужен верстальщик и ему удобнее оперировать голым ХТМЛ и ЦСС.
A>Задача хорошего шаблонного движка сделать так, чтобы они

A>1) правили разные файлы
Пункт 1 как я уже сказал, сделать совсем несложно. Как будет время сделаем, не стоит зацикливаться.

A>2) верстальщику не нужно компилировать и перезапускать приложение
A>3) в супер-супер идеале верстальщику не нужно запускать приложение, а нужно просто открыть хтмл в броузере.
Т.е. на лету считывать файлы и генерировать представление для клиента ?
Это уже посложнее, но думаю не так сложно сделать.

A>Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко. Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф. Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. Но если я правильно понимаю, то система макросов в Немерле такое не потянет, поэтому вы пишете просто "ещё один движок", который в чём-то лучше, в чём-то такой же, в чём-то хуже остальных.
Тут вообще ничего не понял, что за строковые идентификаторы и как их едят, а главное зачем они нужны.

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

M>Нет, неправильно. Максимум, что надо выучить — язык шаблона и пару специфических аттрибутов типа data-bind
И что же нужно выучить в Nemerle.Web кроме "язык шаблона и пару специфических аттрибутов типа data-bind"?
Неужели то, что шаблон лежит в методе View?
Это же просто ужасно сложно.
Ни один верстальщик это никогда в жизни не сможет.

M>Ему его не надо ставить, и разбираться в коде яваскрипта не надо.
Ага. Ага.
Ты хочешь сказать, что ViewModel будет каждый раз править программист?

M>Да-да. Будет только захардкоженый HTML, который будет править программист, ага
Чем он более захардкожен чем в knockoutjs?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

A>>2) верстальщику не нужно компилировать и перезапускать приложение
A>>3) в супер-супер идеале верстальщику не нужно запускать приложение, а нужно просто открыть хтмл в броузере.
_NN>Т.е. на лету считывать файлы и генерировать представление для клиента ?
_NN>Это уже посложнее, но думаю не так сложно сделать.

Если планируется разделение на ХТМЛ файл и прочее, то непонятно какие проблемы с "считывать и генерировать". Файл просто как ресурс идет

A>>Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко. Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф. Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. Но если я правильно понимаю, то система макросов в Немерле такое не потянет, поэтому вы пишете просто "ещё один движок", который в чём-то лучше, в чём-то такой же, в чём-то хуже остальных.
_NN>Тут вообще ничего не понял, что за строковые идентификаторы и как их едят, а главное зачем они нужны.

Они не нужны

Как я уже сказал, они являются проблемой Викета.

http://wicket.apache.org/learn/examples/guestbook.html

_NN>Что такое меняем код ?
_NN>Мы говорим про текст метода 'View' ?

`Lf? yfghbvth

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

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

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

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

1. Вынести это в отдельный файл (верстальщику/дизайнеру вообще даром не упал ни Nemerle, ни студия, ни компиляция)
2. Свести как можно ближе к стандартному HTMLю. Всякое css-is-active, attr-src, css-pinned, style-margin-left, attr-href, css-with-children, css-selected-search-result — в топку.
3. Убрать всю императивщину из HTMLя нафиг (MainPage.Instance.IsActiveNode? Вы с дуба рухнули?). И вообще протягивать внутрь представления вообще всю логику, что реализована в Nemerle — тоже в топку.
4. В шаблон передается ограниченный набор переменных и ограниченный набор инструментов манипуляции с ними, которые легко понять и легко выучить, и с которыми верстальщик может играться как ему угодно. Что-то типа <span class="node-caption {% if active_node == node %} node-active {% endif %}" >

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

Это можно и саму. Можно просто откинуться, взять цитаты

Отдавать разработку таких вьюх дизайнерам имеет мыло смысла. Им лучше отдавать настройку css-а, с помощью которого они смогут управлять внешним видом UI.

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

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

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

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

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

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

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

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

<!doctype html>
    <html ng-app>
    <head>
    <script src="http://code.angularjs.org/1.0.6/angular.min.js"></script>
    </head>
    <body>
    <input type="button" value="set" ng-click="myStyle={color:'red'}">
    <input type="button" value="clear" ng-click="myStyle={}">
    <br/>
    <span ng-style="myStyle">Sample Text</span>
    <pre>myStyle={{myStyle}}</pre>
    </body>
</html>

Я понимаю это не считается "стандартным" HTML ?

    Search: <input ng-model="query">
    Sort by:
    <select ng-model="orderProp">
    <option value="name">Alphabetical</option>
    <option value="age">Newest</option>
    </select>
     
     
    <ul class="phones">
    <li ng-repeat="phone in phones | filter:query | orderBy:orderProp">
    {{phone.name}}
    <p>{{phone.snippet}}</p>
    </li>
    </ul>

А в таком виде "осилит"?

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

A>Если планируется разделение на ХТМЛ файл и прочее, то непонятно какие проблемы с "считывать и генерировать". Файл просто как ресурс идет

Будет видно что и как.
Может хотите помочь проекту ? выглядит на бумаге довольно просто для такой мегафичи

A>Они не нужны

Как я уже сказал, они являются проблемой Викета.
A>http://wicket.apache.org/learn/examples/guestbook.html

Столько кода для простых вещей, как я люблю Java подход

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

_NN>Я понимаю просто иметь спец. атрибут, чтобы не генерировать биндинги и вставить "как есть" ?
_NN>Этого достаточно ?

Что значит "как есть"? Значение переменных по прежнему нужно будет подставлять и раскручивать (т.е. нужен ренедеринг). Но вот биндинг на сервере не нужен уже. Плюс я должен иметь возможность на сервере перехватить факт открытия страницы и срендерить ее содержимое. В общем, как в Разоре.

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

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

Ну, может быть.

M>> Нафига это в шаблоне? Что такое css-is-active? Что за невнятные и непонятные расширения HTMLя?
_NN>Будет документация, будет внятно.

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


_NN>

_NN>А в таком виде "осилит"?

Тоже возможно не осилит

M>> Нафига это в шаблоне? Что такое css-is-active? Что за невнятные и непонятные расширения HTMLя?
_NN>Будет документация, будет внятно.

Нет, не будет. Принципиально неверный подход. В том месте, где knockout предлагает байндинг к данным, не затрагивая основных подходов HTMLя, вы переопределяете половину аттрибутов и CSS ради чего? Да ни ради чего.

// src="$SelectedUrl" ??
<iframe attr-src="$SelectedUrl" frameborder="0" border="0" />

// onclick ??
<div $when(IsLimited) click="$(Search(SearchTerm, false))" class="search-show-all">

// style="margin-left: $(c.Depth * 6)" ??
// class="node $if(c.IsSelected, selected)" ??
<div $foreach(c in Children) style-margin-left="$(c.Depth * 6)" class="node" css-selected-search-result="$(c.IsSelected)">

// src="$(c.IconUrl)" ??
<img class="node-icon" attr-src="$(c.IconUrl)" />

// class="node-pin $if(c.IsPinned, pinned)"
<div $when(!c.HasChildren) click="$(c.TogglePin())" class="node-pin" css-pinned="$(MainPage.Instance.IsPinned(c))" />

Вот зачем на пустом месте огород городить? Кто там говорил про «дизайнеру надо будет только CSS поправить». Если для того, чтобы понять, какой CSS там нагенерится, ему надо прочитать талмуд по «вот вам точно такие же, как в CSS, но совершенно другие аттрибуты», нафиг такой фреймворк нужен?

Это я не говорю об абсолютно непонятном scope контрольных инструкций $when, $foreach и т.п.

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

WH>>Ты хочешь сказать, что ViewModel будет каждый раз править программист?
M>С вашими подходами ничего другого не остается.
А что в knockoutjs иначе?
Если верстальщик захочет связать пару элементов, то ему придется лезть в жабаскрипт.

M>В knockout-js в коде шаблона в идеале вообще не будет яваскрипта. В вашем сверхсупермегафреймворке уже внезапно
Ты действительно не понимаешь, что это всё можно засунуть во ViewModel?

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

WH>>>Ты хочешь сказать, что ViewModel будет каждый раз править программист?
M>>С вашими подходами ничего другого не остается.
WH>А что в knockoutjs иначе?
WH>Если верстальщик захочет связать пару элементов, то ему придется лезть в жабаскрипт.

Скорее всего не придется.

M>>В knockout-js в коде шаблона в идеале вообще не будет яваскрипта. В вашем сверхсупермегафреймворке уже внезапно
WH>Ты действительно не понимаешь, что это всё можно засунуть во ViewModel?

Засовывайте

Пока не засунули, все разговоры о мегакрутизне идут лесом

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

WH>>Если верстальщик захочет связать пару элементов, то ему придется лезть в жабаскрипт.
M>Скорее всего не придется.
Это просто не правда.
Ибо если во ViewModel нет нужного элемента, то нужно будет его туда засунуть.

M>Засовывайте

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

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>

_NN>Суммируя:
_NN>* data-bind="foreach: children"
_NN>* ng-repeat="friend in friends"
_NN>* $foreach(s in Seats)

_NN>Принципиальной разницы не вижу.
_NN>В любом случае верстальщику нужно знать как это правильно писать

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

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

A>Что было бы клёво, так это закадровая компиляция html для интеллисенса в среде.
Одна из причин изначально поставить View в код файла, это упрощение работы подсказок.
Отдельный файл подразумевает интеграцию с Visual Studio, что само по себе не просто.
Рук на все увы не хватает.

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

        <div style-margin-left="6" class="node" class="selected-search-result">
          <a href="http://www.rsdn.ru/test" class="with-children">
            <img class="node-icon" src="http://rsdn.ru/icon" />
            <span class="node-caption" class="is-active">
              SomeText
            </span>
            <div class="node-pin;pinned" />
          </a>
          <div class="node-loading">
            Загрузка, пожалуйста подождите...
          </div>
          <div>
            <!-- Остальные части дерева -->
          </div>
        </div>

А потом добавляет связывание и выборку стилей:

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

css-** означает, добавить class="**" при определенном условии.
attr-** аналогично для атрибутов.
Здесь в макросе все описано как работает.

Пока все логично ?
Теперь тут вам не нравится "$when.." посреди элемента, потому как нельзя будет редактировать HTML.
С этим не поспоришь, можно заменить на что-нибудь в стиле nw-binding="when(...)".
Боле того, в реальном HTML то нет $when, а есть : <div nw-when='...'>. Можете проверить на http://nemerlewebrsdn.apphb.com .

Это близко к тому как должно быть ?

_NN>Ну так оно примерно и сделано.

Вот в этом "примерно" и вся разница

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

Когда верстальщик попытается открыть такой файл в броузере, он не увидит никаких стилей

_NN>Боле того, в реальном HTML то нет $when, а есть : <div nw-when='...'>.

Автоматическую W3C валидацию такой файл не пройдет. В общем случае всё равно, но некоторые заказчики (британские гос. конторы, например) вписывают это в требования к проекту.

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

_NN>>Ну так оно примерно и сделано.

A>Вот в этом "примерно" и вся разница

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

A>Когда верстальщик попытается открыть такой файл в броузере, он не увидит никаких стилей
А что он должен видеть ?
Ведь стиль зависит от разных факторов.
Например может быть
<css-is-active="$X" css-is-not-active="$(!X)">
Что тут он хочет видеть ? Первое или второе ?

Ну или аналогично с атрибутами:
<a attr-href="$("/" + $Something") />
Где планируется передаваться ссылка ?

Если предлагается
<a href="$Something" />
Так можно делать и сейчас.

_NN>>Боле того, в реальном HTML то нет $when, а есть : <div nw-when='...'>.

A>Автоматическую W3C валидацию такой файл не пройдет. В общем случае всё равно, но некоторые заказчики (британские гос. конторы, например) вписывают это в требования к проекту.
Это решается довольно просто.
Вместо nw-when сделать data-nw-when и проблем нет

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

Кстати, хочется отметить, что наконец дискуссия перешла в конструктивное русло.
А криками "все плохо", так и не ясно почему.

Я надеюсь, что именно об этом и говорил Mamut

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

M>Блин. Еще один. Тебе провести урок HTML 101, рассказывающий, как и каким образом можно порушить любую верстку совершенно валидным маркапом?

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

Ту NN. Советую тебе не тратить время на борьбу с невежеством. Те кому это нужно разберутся и поймут, что он не понимает о чем ведет речь.

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

M>Угу. Когда программисты, никогда ничего не делавшие внятного для веба, начинают рассказывать «а, ничего, потом дизайнеры CSS-ом подправят», таких программистов надо отправлять пилить что-нибудь другое, а не веб.

Ты в этой жизни все перепутал. Те кто пилят веб, особенно привычными тебе методами (сравнимыми с каменным топором) — это чернорабочие. Мы с Вольфхаундом этим не знаимаемся, так как можем заниматься вещами сильно более сложными и интеллектуальными. А Веб мы с удовольствием отставляем таким как ты.

Ребята которые мастерят данный фреймоврк тоже несколько (скажем прямо — сильно) интеллектуальнее среднего веб-программиста и потому они не хотят делать примитивный ХТМЛ или писать горы говнокода на Жабаскрипте. По сему они сделали дваижок создания динамического WUI основанный на принципе реактивного программирования и статической типизации.

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

M>«Внутри» надо писать два с половиной байндинга, а не говнокодить захардкоженный HTML внутри кода приложения.

Ты погряз в стереотипах. Мне тебя жаль.

Лучше чем расскзывать о них пойди и попытайся сделать хотя бы отдаленно похожий (а лучше аналогичный) контрол теми методами которые тебе кажутся приемлемыми. Потом покажи результат нам и мы сравним его с тем что есть у ionoy и _NN_.

А до тех пор ты можешь говорить все что угодно. Лично для меня это будет просто пустопорежний треп.

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

M>Да-да. Будет только захардкоженый HTML, который будет править программист, ага

Любишь же ты трепаться без дела. Давно бы уже попробовал свои мега-идеи в деле.

Вот тебе реализация простенького дерева с подгрузкой элементов (как в нашем случае) написанное традиционными методами:
http://javascript.ru/ui/ajaxtree
Ниже приведен его основной исходник. Обрати внимание где там эти самые шаблоны которые будет править твой верстальщик.

function tree(id, url)
{
  var element = document.getElementById(id)
  function hasClass(elem, className)
  {
    return new RegExp("(^|\\s)" + className + "(\\s|$)").test(elem.className)
  }
  function toggleNode(node)
  {
    // определить новый класс для узла
    var newClass = hasClass(node, 'ExpandOpen') ? 'ExpandClosed' : 'ExpandOpen'
    // заменить текущий класс на newClass
    // регексп находит отдельно стоящий open|close и меняет на newClass
    var re = /(^|\s)(ExpandOpen|ExpandClosed)(\s|$)/
    node.className = node.className.replace(re, '$1' + newClass + '$3')
  }
  function load(node)
  {
    function showLoading(on)
    {
      var expand = node.getElementsByTagName('DIV')[0]
      expand.className = on ? 'ExpandLoading' : 'Expand'
    }
    function onSuccess(data)
    {
      if (!data.errcode)
      {
        onLoaded(data)
        showLoading(false)
      } else
      {
        showLoading(false)
        onLoadError(data)
      }
    }
    function onAjaxError(xhr, status)
    {
      showLoading(false)
      var errinfo = { errcode: status }
      if (xhr.status != 200)
      {
        // может быть статус 200, а ошибка
        // из-за некорректного JSON
        errinfo.message = xhr.statusText
      } else
      {
        errinfo.message = 'Некорректные данные с сервера'
      }
      onLoadError(errinfo)
    }
    function onLoaded(data)
    {
      for (var i = 0; i < data.length; i++)
      {
        var child = data[i]
        var li = document.createElement('LI')
        li.id = child.id
        li.className = "Node Expand" + (child.isFolder ? 'Closed' : 'Leaf')
        if (i == data.length - 1) li.className += ' IsLast'
        li.innerHTML = '<div class="Expand"></div><div class="Content">' + child.title + '</div>'
        if (child.isFolder)
        {
          li.innerHTML += '<ul class="Container"></ul>'
        }
        node.getElementsByTagName('UL')[0].appendChild(li)
      }
      node.isLoaded = true
      toggleNode(node)
    }
    function onLoadError(error)
    {
      var msg = "Ошибка " + error.errcode
      if (error.message) msg = msg + ' :' + error.message
      alert(msg)
    }
    showLoading(true)
    $.ajax({
      url: url,
      data: node.id,
      dataType: "json",
      success: onSuccess,
      error: onAjaxError,
      cache: false
    })
  }
  element.onclick = function (event)
  {
    event = event || window.event
    var clickedElem = event.target || event.srcElement
    if (!hasClass(clickedElem, 'Expand'))
    {
      return // клик не там
    }
    // Node, на который кликнули
    var node = clickedElem.parentNode
    if (hasClass(node, 'ExpandLeaf'))
    {
      return // клик на листе
    }
    if (node.isLoaded || node.getElementsByTagName('LI').length)
    {
      // Узел уже загружен через AJAX(возможно он пуст)
      toggleNode(node)
      return
    }
    if (node.getElementsByTagName('LI').length)
    {
      // Узел не был загружен при помощи AJAX, но у него почему-то есть потомки
      // Например, эти узлы были в DOM дерева до вызова tree()
      // Как правило, это "структурные" узлы
      // ничего подгружать не надо
      toggleNode(node)
      return
    }
    // загрузить узел
    load(node)
  }
}

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

Теперь сравни это с подходом из Nemerle.Web. Код и представление разделены. Причем код разделен на логику представления (Viw Model) и логику данных. Все что отвечает за рендеринг ХТМЛ-я выделено в отдельный шаблон. Код статически типизирован. Работает комплит, подсветка, навигация и рефакторинг:

using Nemerle;
using Nemerle.Collections;
using Nemerle.Text;
using Nemerle.Utility;

using System;
using System.Collections.Generic;
using System.Linq;
using NemerleWeb;
using NemerleWeb.TypedJS;

namespace NemerleWeb.Rsdn
{  
  [Unit]
  public class TreeNode
  {
    public Id : string { get; set; }
    public Caption : string { get; set; }
    public Href : string { get; set; }
    public Icon : string { get; set; }
    public Hide : bool { get; set; }
    public Depth : int { get; set; }
    public IsOpened : bool { get; set; }
    public Children : List[TreeNode] { get; set; }    
    public HasChildren : bool { get; set; }
    
    public Parent : TreeNode { get; set; }
    public IsLoading : bool { get; set; }    
    public IsSelected : bool { get; set; }
    
    public IconUrl : string 
    {      
      get {        
        def suffix = match(IsOpened, HasChildren) {
                      | (false, true) => "c.gif" 
                      | (true, _) => "o.gif";
                      | _ => "s.gif";
                     };
        "http://rsdn.ru/images/tree/" + Icon + suffix;
      }
    }
    
    public TogglePin() : void
    {            
      if(!MainPage.Instance.IsPinned(this)) MainPage.Instance.AddPinned(Id)
      else MainPage.Instance.RemovePinned(Id)
    }
    
    public CaptionClick() : void
    {
      if(HasChildren) {
        if(Children == null) {
          IsLoading = true;
          IsOpened = !IsOpened;
          server.LoadNodeChildren(Id, children => {           
            Children = children;
            
            foreach(child in Children)
              child.Parent = this;
              
            IsLoading = false;
          });
        } else
          IsOpened = !IsOpened;
      }
      else { 
        if(window.@event.ctrlKey)
          _ = window.open("http://www.rsdn.ru" + this.Href, "_blank", null, false);
        else
          MainPage.Instance.SelectNode(this);
      }
    }
    
    [Html]
    public View() : string
    {
      <#
        <div $foreach(c in Children) style-margin-left="$(c.Depth * 6)" class="node" css-selected-search-result="$(c.IsSelected)">
          <a click="$(c.CaptionClick())" attr-href="$("http://www.rsdn.ru" + c.Href)" css-with-children="$(c.HasChildren)">
            <img class="node-icon" attr-src="$(c.IconUrl)" />
            <span class="node-caption" css-is-active="$(MainPage.Instance.IsActiveNode(c))">
              $(c.Caption)
            </span>
            <div $when(!c.HasChildren) click="$(c.TogglePin())" class="node-pin" css-pinned="$(MainPage.Instance.IsPinned(c))" />
          </a>
          <div $when(c.IsLoading) class="node-loading">
            Загрузка, пожалуйста подождите...
          </div>
          <div $when(c.IsOpened && Children != null)>
            <div template="$(template(c))" />
          </div>
        </div>
      #>
    }
    
    public class Server
    {
      public LoadNodeChildren(id : string) : List[TreeNode]
      {
        TreeLoader.LoadNodeChildren(id)
      }
    }
  }
}

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

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

Ну, а с выносом представления в отдельый файл есть объективные сложности. Интеграция Немерла не умеет работать с внешними ДСЛ-ями. То есть компилировать это дело можно из внешнего файла, но комплита, навигации и прочих прелестей IDE не будет. Вот допилим Н2 — внешние ДСЛ-и можно будет делать так же просто как и внутренние.

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

M>В knockout-js в коде шаблона в идеале вообще не будет яваскрипта. В вашем сверхсупермегафреймворке уже внезапно
M>

M>MainPage.Instance.IsActiveNode(c)
M>MainPage.Instance.IsPinned(c)
M>string.IsNullOrEmpty(SearchTerm)
M>

НокаутЖС был прототипом для данной библиотеки. Все что можно на Накауте, можно и на НемерлеВеб.

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

M>Или знай Немерле или катись к черту, ага.

А что ты хотел? Те кто не хочет учить язык на котором такие библиотеки пишутся двумя парнями без отрыва от стужи (с) ~~сосут~~ ~~быдлокодяд~~ кодируют на супер-языке JavaScript и мечтают кода для их любимого языка большие дяди из Майкрософт или Гугль сделают что-то похожее.

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

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

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

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

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

В общем, ты сравниваешь очень разные задачи. НемерлВеб решает задачу создания интерактивного WUI. И делает так, что то что раньше нельзя было представить в виде шаблона, становится доступно в виде обособленного представления. Ну, а биндинги и код ViewModel — это минимально необходимое зло. Без него будет только сложнее.

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

F>> Кстати, а кто ещё умеет немножко генерить JS? Ну GWT не берём — я его ниасиливаю.

A>Например, liftweb

Почитал. Про генерацию жабаскрипта ничего не заметил. Есть что-то вроде обработки форм через аджакс. Но это как и рядом не стояло.

Можно по подробнее о том где, как и зачем Лифт генерирует жабаскрипт и как на базе этого смастерить то же интерактивное деревце, например?

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

A>Задача хорошего шаблонного движка сделать так, чтобы они

Ага. Только одно "но". Речь не идет о шаблонном движке.

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

A>Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко.

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

A>Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф.

В этом нет ничего естественного. Это — косяк.

A>Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм.

Ты, видимо, тоже попутал какой-то шаблонный движок (которых 100500) с MVVM-фреймворком. Это как бы настолько разные вещи, что даже сравнивать их не стоит.

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

_NN>Может хотите помочь проекту ? выглядит на бумаге довольно просто для такой мегафичи

\\

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

A>>Они не нужны

Как я уже сказал, они являются проблемой Викета.
A>>http://wicket.apache.org/learn/examples/guestbook.html

_NN>Столько кода для простых вещей, как я люблю Java подход

Все еще смешнее. Это серверный код! К клиентскому жабаскрипту это не имеет никакого отношения.

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

A>

A>   <input type="text" name="name"/>
A>   <input type="text" name="age"/>
A>   <input type="submit" />
A>------------------------------------------------------
A> public submit(ApplicationFormPage.ApplicationForm form): ... {
A>  ...
A>  form.Name
A>  form.Age
A>

A>Вообщем, в Немерле коде я не силен, но идея я думаю понятна. HTML компилируется на лету и создаются необходимые файлы, доступен intellisens, нельзя написать page.SearchForm, потому что такой формы нет на странице, если со страницы удаляется поле name то перестаёт компилироваться код page.ApplicationForm.Name.visible. Причем тут есть куда ещё развернуться, например указывать для формы на какой класс нужно биндить поля формы (<form id=".." nweb:bind="ApplicationModel">) и создавать этот биндинг автоматически

Я правильно понял, что submit на сервере выполняется? Если так, то я поздравляю тебя. Ты изобрел Asp.Web.Forms образца 2002-го года. Подход признана тупиковым.

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

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

A>

A><html xmlns:nweb="https://github.com/NemerleWeb/NemerleWeb/"
A>xmlns:nwebtree="https://github.com/NemerleWeb/NemerleWeb/Tree">
A> <body>
A>   <div nweb:component="TreeComponent" nwebtree:level="root">
A>     Это корень
A>     <div nwebtree:node="expanded-node" nwebtree:level="1" style="font-weight:bold;color:blue;..." или class="..."> 
A>       Это распахнутый узел уровня 1
A>       <div nwebtree:node="expanded-node" nwebtree:level="2" style="font-weight:bold;color:red;..." или class="..."> 
A>

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

Короче, тебе нужно для начала понять что такое MVVM.

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

Это всё реализовано много где и лучше и хуже. Например, в GWT, мне кажется, реализовано лучше.

VD>В традиционном подходе вообще нечего этому самому верстальщику дать.

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

VD>В общем, ты сравниваешь очень разные задачи. НемерлВеб решает задачу создания интерактивного WUI.

Эту задачу уже 10 лет решают. И знаешь почему её не решили? Потому что её решают программисты, которые понятия не имеют о труде верстальщика и верхом совершенства считают как можно более красивое смешивание ХТМЛ кода и биндингов, и у них в голове не умещается, что это просто надо разделить на 2 разных файла. Верстка РСДН идеальное тому подтверждение. Я пытался настроить свои стили и скрипты для РСДН, как делал это для многих сайтов, которыми пользуюсь постоянно — более недружественной верстки я просто никогда не встречал.

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

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

F>>> Кстати, а кто ещё умеет немножко генерить JS? Ну GWT не берём — я его ниасиливаю.

A>>Например, liftweb

VD>Почитал. Про генерацию жабаскрипта ничего не заметил.

вот пример
http://cookbook.liftweb.net/#ClientSideOnlyActions

вот список всех JS команд, которые можно сгенерировать на сервере для исполнения на клиенте
http://exploring.liftweb.net/onepage/index.html#toc-Subsection-10.1.1

вот ещё пример
http://exploring.liftweb.net/onepage/index.html#lst:Client-side-comparisons

VD>Можно по подробнее о том где, как и зачем Лифт генерирует жабаскрипт и как на базе этого смастерить то же интерактивное деревце, например?

Ну вот подгрузка подуровня, например

http://exploring.liftweb.net/onepage/index.html#lst:Tree-example

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

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

A>>Задача хорошего шаблонного движка сделать так, чтобы они

VD>Ага. Только одно "но". Речь не идет о шаблонном движке.

Это я уже понял и именно это мне и не нравится

VD>Я правильно понял, что submit на сервере выполняется? Если так, то я поздравляю тебя. Ты изобрел Asp.Web.Forms образца 2002-го года. Подход признана тупиковым.

АспВебФормс — это такая же мешанина кода и разметки, как NW — значит ли это что вы тоже его изобретаете?

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

Я веб разработкой занимался 10 лет — достаточный срок, чтобы понять, что мне не нравится смесь разметки и кода (собственно то, с чем Мамут в тему зашел).

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

VD>Это не взлетит просто потому может случиться комбинаторный взрыв. Да и объем кода будет неподъемным.

А может и не случиться.

VD>Короче, тебе нужно для начала понять что такое MVVM.

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

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

>вот список всех JS команд, которые можно сгенерировать на сервере для исполнения на клиенте
>http://exploring.liftweb.net/onepage/index.html#toc-Subsection-10.1.1

Писать АСТ ? Это не по нашему.

Хотя ,тут слухи о макросах в скале идут, возможно придут к тому как в NemerleWeb.

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

A>Он хочет видеть и первое и второе, посмотри мой пример.

Это надо хорошо обдумать как размечать где предварительный дизайн, и что заменять на настоящий.
В данном примере, я понимаю wicket просто знает как работать с <select>. А с произвольными тегами как будет ?

Есть еще такая тема, что каждый юнит не является полным HTML файлом, а всего лишь куском документа.
Насколько редактор и валидатор смогут это осилить ?
Или тут тоже предполагается, что движок может убрать лишние теги html, head, body и оставить только то, что внутри ?

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

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

A>>Он хочет видеть и первое и второе, посмотри мой пример.

_NN>Это надо хорошо обдумать как размечать где предварительный дизайн, и что заменять на настоящий.
_NN>В данном примере, я понимаю wicket просто знает как работать с <select>. А с произвольными тегами как будет ?

Плохо будет. Точнее никак не будет

Но если разработать свой кастомный компонент (а Викет в первую очередь компонентно-ориентированный фр-рк), то работать будет. Но поддержка на уровне ИДЕ не появится, на уровне комилятора — тоже. Потому что stringly-typed и на Яве никуда не деться от этого

_NN>Есть еще такая тема, что каждый юнит не является полным HTML файлом, а всего лишь куском документа.
_NN>Насколько редактор и валидатор смогут это осилить ?
_NN>Или тут тоже предполагается, что движок может убрать лишние теги html, head, body и оставить только то, что внутри ?

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

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

A>Плохо будет. Точнее никак не будет

Но если разработать свой кастомный компонент (а Викет в первую очередь компонентно-ориентированный фр-рк), то работать будет. Но поддержка на уровне ИДЕ не появится, на уровне комилятора — тоже. Потому что http://neologisms.rice.edu/index.php?a=term&d=1&t=14876 и на Яве никуда не деться от этого
Ну вот, а нам то нужны произвольные теги.
Иначе в чем профит.

A>Я размышлял вслух про свой идеал. Думаю, что чисто средствами языка (пусть и мощного, как Немерле) он вряд ли реализуем. Тут скорее важна хорошая поддержка в ИДЕ, но если есть поддержка в ИДЕ, то уже и мощный язык не нужен

В N2 можно будет

Давайте обсуждать этот идеал и смотреть как прийти к этому в NemerleWeb.
Учитывая опыт разработки веб это будет очень полезно.

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

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 — в топку.

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

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

Это фичи/издержки MVVM. Без них MVVM плохо приспособлен к реальной жизни.

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

В шаблон передается вся VM, это опять же фичи/издержки MVVM. Ограничивать набор манипуляций — действие противоположное общему вектору идеологии фреймворка, в топку.

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

Тут ты прав.

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

В нокауте совершенно то же самое. То, что эти расширения засунуты в data-binding для немножечко программиста почти ничего не меняет.

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

A>Например, liftweb

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

A>Викет умеет, правда он на Яве и слегка многословно смотрится.

Wicket тоже не умеет.

Вот GWT умеет. Но он ничего не знает про MVVM. Так что в Вебе у НемерлВеб прямых аналогов нет. Есть KnockoutJS и AngularJS, но это жабаскрипт-библиотеки. Совмещение статической типизации и MVVM для Web есть только в ZK Framework. И то не уверен, что у них биндинги проверяются.

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

A>вот пример
A>http://cookbook.liftweb.net/#ClientSideOnlyActions

И что мы там видим? Генерацию жабаскрипта в виде строк и объектов-оберток.

A>вот список всех JS команд, которые можно сгенерировать на сервере для исполнения на клиенте
A>http://exploring.liftweb.net/onepage/index.html#toc-Subsection-10.1.1

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

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

VD>>Можно по подробнее о том где, как и зачем Лифт генерирует жабаскрипт и как на базе этого смастерить то же интерактивное деревце, например?

A>Ну вот подгрузка подуровня, например
A>http://exploring.liftweb.net/onepage/index.html#lst:Tree-example

И что же мы там видим?

The TreeView widget transforms an unordered list (<ul>) into a tree-like structure using the TreeView JQuery plugin [K] [K] http://docs.jquery.com/Plugins/Treeview.

Ты наверно что-то не понимаешь. Код приведенный TreeNode.n — это самодостаточный код. Он не использует никаких внешних компонентов или внешнего жабаскрипта.

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

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

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

A>А где у меня написано, что Викет умеет клиентский ЯваСкрипт?

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

A>Я утверждал, что Викет идет по правильному пути с точки зрения разделения HTML и кода.

Ошибочно утверждал.

A> ЛифтВеб умеет клиентский ЯваСкрипт

В таком виде его все имеют. Подход называется — закат солнца вручную.

A>и умеет разделять ХТМЛ и код, так что он дальше всех пошел.

Ты зациклился на этом разделение. Несомненно это хорошо. Но это не единственная переменная в уравнении.

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

Вольфаунд предложил использовать архитектурный паттерн MVVM, который на тот момент почти нигде (кроме WPF и НокаутаЖС) не был реализован.

Совмещение мощного статически типизированного языка, декларативный биндинга (вместо обработки событий и груды кода), и другие прелести MVVM делают программирование на нем намного более продуктивным.

A>>>Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм.
VD>>Ты, видимо, тоже попутал какой-то шаблонный движок (которых 100500) с MVVM-фреймворком. Это как бы настолько разные вещи, что даже сравнивать их не стоит.

A>Никакая магическая аббревиатура не делает NW уникальным. Сейчас все всё умеют (ну или пытаются) и все у всех всё заимствуют. А называться это в каждом месте может как угодно.

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

Сейчас у тебя есть два пути. Пойти и разобраться том о чем тебе говорят (MVVM) или окончательно свалиться в паттерн поведения "Блаб-программист" и продолжить самоуверенно спорить о том в чем ничего не понимаешь.

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

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

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

VD>>Я правильно понял, что submit на сервере выполняется? Если так, то я поздравляю тебя. Ты изобрел Asp.Web.Forms образца 2002-го года. Подход признана тупиковым.

A>АспВебФормс — это такая же мешанина кода и разметки, как NW — значит ли это что вы тоже его изобретаете?

Ты не ответил на вопрос. submit на сервере выполняется?

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

Поняв то в Майкрософте создали MVC ASP .NET-движек и факрически забили на вебформы.

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

A>Я веб разработкой занимался 10 лет — достаточный срок, чтобы понять, что мне не нравится смесь разметки и кода (собственно то, с чем Мамут в тему зашел).

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

Я точно так же услышал о MVVM и пошел с ним разбираться. Не сразу это получилось. Но когда я осознал эту идеологию, то понял, что для интерактивного клиент-сервеного UI — это то что надо. Биндинг позволяет в деларативной (и краткой) форме описать то, на что раньше приходилось писать тонны кода. Сама модель позволят реально выделить мелкие представления, а не хардкодить их внутри кода и не навораяивать над ними тонны боллерплэйт-кода, как это принято в вбиблиотеха вроде Лийта.

VD>>Это не взлетит просто потому может случиться комбинаторный взрыв. Да и объем кода будет неподъемным.

A>А может и не случиться.

В общем случае — случится. У тебя есть измерение свойств вертки, и измерение случаев использования. Количество случаев будет их перемножение.

VD>>Короче, тебе нужно для начала понять что такое MVVM.

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

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

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

Можно название хорошего фреймворка в студию? А то что-то в продакшене я таких не видал...

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

Почитал ветку..

Раскажу только свой скромный опыт.
У нас вьюхи на jsp и на ftl (free marker template), но смысл одинаковый — это html с вкраплениями специальных тегов.
Проекты — не самый простой html, часто много динамики, которая достигается упомянутыми спец тегами + java script (в основном jQuery).

Команда дизайнеров отдельная. Дизайнер делает вначале макет — в графическом редакторе, потом по макету верстальщик пишет верстку в html + css (+ иногда не самый лучший java script, чтобы показать как должно работать). На выходе у верстальщиков свой проект состоящий из html, css, javascript, в их собственном репозитории, не пересекающимся с девелоперским.

Программист получает верстку, css и должен их внедрить. По сути на этом этапе легкая часть — копипаст верстки, более сложная часть — добавление динамики и связывание с серверным кодом. Наверно тут для программиста все равно где будет храниться html: в jsp, ftl или исходных файлах nemerle.

Теперь что делать если в реализованной верстке найден баг.
Задачю ревьвит программист. Если видит что это он накосячил, когда переносил — исправляет. В противном случае отдает верстальщику. Далее:
1) Если верстальщик не "чуть программист" то он меняет только их html проект. И переводит задачу программисту, а тот уже переносит изменения.
2) Если верстальщик "чуть программист" то он может сам поправить jsp или ftl. В больщинстве случаев он может забить на непонятные для него специальные теги фреймворков, и сделать точечные изменения в тех местах где это нужно. Компилит проект, поднимает сервер, тестирует, и если все ок — переводит таску дальше по процессу.
Кстати, у нас верстальщики никогда javascript в основном проекте не меняют, только верстку и стили.

И вот теперь вопрос, не будет ли для вертальщика слишком шокирующим залезть править nemerle файлы. Мамут считает что будет. С одной стороны он прав, т.к. к примеру jsp, ftl — это "почти html" c вкраплениями спец тегов. А в Nemerle? Судя по примерам это больше выглядит как немерле файлы с вкраплениями html. Так что могу предположить что порог "чуть программистов" должен быть немного выше, чтобы для исправления багов пойти по описанному выше пути 2. Но считать это чем то супер критичным — хз, не уверен.

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

GT>Раскажу только свой скромный опыт...
GT>Команда дизайнеров отдельная. Дизайнер делает вначале макет — в графическом редакторе, потом по макету верстальщик пишет верстку в html + css (+ иногда не самый лучший java script, чтобы показать как должно работать). На выходе у верстальщиков свой проект состоящий из html, css, javascript, в их собственном репозитории, не пересекающимся с девелоперским.

GT>Программист получает верстку, css и должен их внедрить. По сути на этом этапе легкая часть — копипаст верстки, более сложная часть — добавление динамики и связывание с серверным кодом...

Этот подход и для NemerleWeb прекрасно подойдет. Более того за счет того, что MVVM позволяет лучше выделять представление — этот подход будет работать даже лучше на NemerleWeb.

Единственное что может помешать — это то что MVVM-подход подталкивает к декомпозиции представления (кода тоже, но это на дизайнеров не влияет).

GT>Наверно тут для программиста все равно где будет храниться html: в jsp, ftl или исходных файлах nemerle.

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

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

GT>Теперь что делать если в реализованной верстке найден баг...
GT>1) Если верстальщик не "чуть программист" то он меняет только их html проект. И переводит задачу программисту, а тот уже переносит изменения.

Ну, это и в NemerleWeb, естественно, можно сделать.

GT>2) Если верстальщик "чуть программист" то он может сам поправить jsp или ftl. В больщинстве случаев он может забить на непонятные для него специальные теги фреймворков, и сделать точечные изменения в тех местах где это нужно. Компилит проект, поднимает сервер, тестирует, и если все ок — переводит таску дальше по процессу.

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

GT>Кстати, у нас верстальщики никогда javascript в основном проекте не меняют, только верстку и стили.

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

GT>И вот теперь вопрос, не будет ли для вертальщика слишком шокирующим залезть править nemerle файлы. Мамут считает что будет.

Сдается мне, что Мамут просто переносит свои стереотипы на подход который он видит в первые. Чудес не бывает и за любые удобства чем-то приходится платить.

Ты выше сказал, что перенос верстки — это относительно простой процесс, в основном сводящийся к копипасте. Лично я с этим согласен.
Основная сложность, все же — это написание прикладного кода и "оживление" интерфейса. В традиционном подходе "оживление" интерфейса обычно сводится к написанию кучи кода на жабаскрипте. MVVM же (и, соответственно, NemerleWeb) позволяют не только использовать один из мощнейших на сегодня, статически типизированных языков, но и вообще избавиться от программирования связанного с UI (за счет биндинга). Это существенно упрощает разработку и сопровождение решений в которых много сложного WUI. И все что требуется в замен — объяснить верстальщикам принципы MVVM (в особенности биндинг). Думаю, что это очень хорошая цена за ускорение разработки и упрощение сопровождения.

GT>С одной стороны он прав, т.к. к примеру jsp, ftl — это "почти html" c вкраплениями спец тегов. А в Nemerle?

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

GT>Судя по примерам это больше выглядит как немерле файлы с вкраплениями html.

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

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

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

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

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

...

В смысле нет джаваскрипта? Судя по http://nemerlewebsamples.apphb.com/ он генерирутся? Если так то есть следующие вопросы.
1) Что если надо сделать что-то в джаваскрипте, что нельзя сделать средставами NemerleWeb? Или можно написать все что угодно и это будет скопмилировано в любой javascript?
2) Как быть с джаваскриптовыми библиотеками и компонентами. Например jQuery и его плагины, можно ли их использовать? Ведь написаны тысячи бесплатных и очень качественных джаваскриптовых конролов и компонент, под любые задачи.
3) Можно ли писать код активно взаимодействующий с браузером? Имею в виду подписываться на эвенты браузера, использовать file api, history api. Можно ли писать код специфичный для браузера (например реализовать какой-то воркэраунд для IE8 который много чего не поддеривает?
4) Если наблюдается некая бага в динамической части сайта, то часто способ ее решения это в консоли браузера поиграться с джаваскриптовыми функциями (а я знаю с какими, ведь я их сам писал), и посмотреть, что получается. Как быть в случае немерле веб, смогу ли я с легкостью разобраться со сгенерированными джаваскриптами и поиграться с ними. А если найду баг в джаваскрипте, то легко ли мне будет найти код, который сгенерировал этот джаваскрипт? А если выяснится что бага в генераторе джаваскрипта?

Более философский вопрос.
5) Допустим я решил поменять работу, и на новой работе не используют немерле, но больше традиционные подходы к веб программированию. Смогу ли я применить свой опыт в традиционных проектах? Или придется переучиваться и перестраивать мышление?

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

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

Все уже давно решено: Типизация JS.

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

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

Вопросы скорее к авторам библиотеки, но попробую ответить в меру своих знаний.

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

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

GT>Если так то есть следующие вопросы.
GT>1) Что если надо сделать что-то в джаваскрипте, что нельзя сделать средставами NemerleWeb? Или можно написать все что угодно и это будет скопмилировано в любой javascript?

С точки зрения вычислительных возможностей все языки полные по Тьюрингу эквивалентны, так что все что можно на одном языке, можно и на другом. Так что камнем преткновения тут является только API. Использовать нетипизированный API напрямую из Немерла нельзя, но есть два обходных пути:
1. Создание типизированной обертки над нетипизированным API.
2. Использование вставок на годом JS. Но лично мне этот вариант тянет только на средство быстро "заткнуть дыру".

GT>2) Как быть с джаваскриптовыми библиотеками и компонентами. Например jQuery и его плагины, можно ли их использовать? Ведь написаны тысячи бесплатных и очень качественных джаваскриптовых конролов и компонент, под любые задачи.

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

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

Для file и history можно легко написать обертку или генерировать ее по TypeScripr автоматически. Вот с DOM-ом напрямую лучше не общаться. Хотя, если приспичит, то на крайний случай можно.

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

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

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

А вообще, просто погляди код и оцени сам.

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

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

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

GT>А если найду баг в джаваскрипте, то легко ли мне будет найти код, который сгенерировал этот джаваскрипт?

Код разбит на функции и типы. Так что не думаю, что с этим будут проблемы. Сложнее будет понять генерируемый код в следствии довольно сильных различий в языках и кучи генерируемых goto. Например, немерл поддерживает паттер-матчинг аналогов которому в жабаскрипте нет. Это приводит к тому, что код ПМ переписывается в не хилую простыню. Но функцию с ошибкой точно можно найти. Далее ее можно просто разбить и найти ошибку.

GT>А если выяснится что бага в генераторе джаваскрипта?

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

GT>Более философский вопрос.
GT>5) Допустим я решил поменять работу, и на новой работе не используют немерле, но больше традиционные подходы к веб программированию. Смогу ли я применить свой опыт в традиционных проектах? Или придется переучиваться и перестраивать мышление?

MVVM применяется во всех свежих GUI-билитеках от MS (WPF, Silverlight, WinRT). В вебе есть только нетипизированные аналоги: knockoutjs и AngularJS. В Ява-мире возможно что-то есть в ZK Framevwork (согласно Педивикии, сам не разбирался).

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

Ну, компиляторов в JS на сегодня хватает. Есть и с Явы (GWT) и с C# и с более экзотических языков (например, Котлин из коробки это умеет). Но в NemerleWeb интересно именно сочетание MVVM и генерации кода со статически типизированного языка. Плюс сам язык очень мощный и приятный. После него когда пишеш на Яве или C# просто ломка начинается. А что могут его макросы видно хотя бы на базе этого проекта. В нем почти все на макросах сделано.

Ну, и никто не мешает притащить NemerleWeb и Nemerle в новую контру. Умный руководитель оценит упрощение и ускорение разработки. Тут как и в любом деле риски против выгоды. Оцениваешь и выбираешь.

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

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

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

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

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

Здравствуйте, 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 все может

Здравствуйте, 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 крут в сравнении с обычным подходом, не на словах, а в реальном проекте..

Здравствуйте, 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 вполне реальный проект.
И если в итоге этот код заменит оригинальный на этом форуме, разве это не достаточно показательно ?

Здравствуйте, 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, то у тебя получилась бы простыня на три-четыре страницы плохо поддерживаемого императивного кода.

Здравствуйте, 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 удаляется. -->
      ...
    #>

Здравствуйте, 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
Это автоматом работает, если я не ошибаюсь.

Здравствуйте, 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>Это автоматом работает, если я не ошибаюсь.

Тогда в чем проблема? Почему его не использовать?

Здравствуйте, 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>Тогда в чем проблема? Почему его не использовать?
Потому что, по моему мнению, это более грязный вариант, несмотря на то, что он может быть более понятным для человека, который в первый раз видит фреймворк.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Язык как язык. Поддержка ООП есть в CoffeeScript и TypeScript. Второй, вдобавок, статически типизирован.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 я привел примеры проблем. Где благодарность? Нету. "Потому что ты так до сих пор и не понял, какая цель этого фреймворка." По ходу, он настолько мега-гениальный, что цель этого фреймворка известна только вам.

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

M>>Это — ложь, потому что HTML'я надо писать тоже много. У вас весь туториал состоит из того, как вы меняете HTML.
_NN>Снова по кругу ?
_NN>Почему не написать в стиле: "Вместо того чтобы менять HTML , лучше делать так и так потому эдак и эдак".

Стоп. Это авторы и им сочувствующие этого фреймворка орут "ХТМЛ писать не надо!!! мегакруто!!! вы тупые и ничего не понимаете!!! идите читайте туториал!!! реактивность!!! компоненты!!!"

_NN>Пока высказался только avpavlov о том, что неудобно когда HTML в том же файле что и код.

С этого, вообще-то, начал я. avpavlov просто это причесал в более понятную форму для людей, которые априори считают всех других тупыми. Почему-то для вас приходится все разжевывать, а вот как только требуешь внятных ответов от вас — "вы тупые, вы не поняли цели фреймворка, идите читайте туториал". Я прочитал, возникли вопросы и критика с примерами: http://rsdn.ru/forum/nemerle/5245188.1 Ответ? "ты так до сих пор и не понял, какая цель этого фреймворка."

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

M>Стоп. Это авторы и им сочувствующие этого фреймворка орут "ХТМЛ писать не надо!!! мегакруто!!! вы тупые и ничего не понимаете!!! идите читайте туториал!!! реактивность!!! компоненты!!!"
Я никого тупым не называл. Не нужно приписывать мне чужие слова.

_NN>>Пока высказался только avpavlov о том, что неудобно когда HTML в том же файле что и код.
M>С этого, вообще-то, начал я. avpavlov просто это причесал в более понятную форму для людей, которые априори считают всех других тупыми. Почему-то для вас приходится все разжевывать, а вот как только требуешь внятных ответов от вас — "вы тупые, вы не поняли цели фреймворка, идите читайте туториал". Я прочитал, возникли вопросы и критика с примерами: http://rsdn.ru/forum/nemerle/5245188.1 Ответ? "ты так до сих пор и не понял, какая цель этого фреймворка."
Ну если не было изначально понятно почему не объяснить

Да, нужно писать HTML !
Лучше ?

В том же ASP.NET MVC тоже нужно писать HTML и менять на каждый чих, но почему-то там это нормально.

Наш подход сроден AngularJS, в котором тоже надо менять HTML.
В отличии от AngularJS наш фреймворк дает статическую типизацию , таким образом уменьшая количество ошибок.
Далее NemerleWeb дает возможность пользоваться макросами Nemerle, что еще больше повышает продуктивность и упрощает разработку.

Улучшать туториал несомненно нужно раз не все ясно. Как будет время допишем.

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

I>>То есть проблема всё-таки в туториале, а не в фреймворке?
M>Мне про фреймворк ничего неизвестно. Кроме туториала. В котором про фрейморк вообще ничего внятного не говорится. Замкнутый круг.
Туториал написан для людей, которые уже сталкивались с реактивными фреймворками. Но ты прав, надо более подробно объяснить что из себя представляет этот фреймворк и какие задачи он решает. Иначе возникают недопонимания.

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

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

M>В последних трех-четырех сообщениях я последовательно говорил о проблемах с туториалом и описаниями. Где благодарность? Не вижу. Вижу только "ты тупой, иди читай туториал". Более того, тут: http://rsdn.ru/forum/nemerle/5245188.1 я привел примеры проблем. Где благодарность? Нету.
Твоя критика в том сообщении к нашему фреймворку ну никак не относится, поэтому никто её серъёзно и не воспринимает. Тебе _NN_ уже выше ответил, но я повторюсь: во всех подобных фреймворках надо лопатить HTML, мы не компоненты предоставляем, а упрощаем написание client side логики и взаимодействие с сервером. От HTML никуда не уйдёшь (да и не хочется).
M>"Потому что ты так до сих пор и не понял, какая цель этого фреймворка." По ходу, он настолько мега-гениальный, что цель этого фреймворка известна только вам.
Нет, просто ты на протяжении всей ветки пытаешься оспорить основы фреймворка, а не конкретные реализации.

От:	ionoy	www.ammyui.com
Дата:	23.05.13 15:38
Оценка:	331 (12)

	От:	avpavlov
	Дата:	26.06.13 16:33
	Оценка:	23 (2)

От:	Mamut	http://dmitriid.com
Дата:	28.07.13 15:58
Оценка:	4 (2)

	От:	avpavlov
	Дата:	27.06.13 14:53
	Оценка:	1 (1) +1

От:	ionoy	www.ammyui.com
Дата:	29.07.13 17:27
Оценка:	+2

	От:	Аноним
	Дата:	26.05.13 18:59
	Оценка:	1 (1)

От:	VladD2	www.nemerle.org
Дата:	24.05.13 08:41
Оценка:	+1

От:	_NN_	www.nemerleweb.com
Дата:	27.06.13 19:31
Оценка:	+1

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	13.06.13 17:25
Оценка:

	От:	WolfHound
	Дата:	25.05.13 13:13
	Оценка: