VD>А вот когда речь идет о разработке интерактивных фишек вроде дерева, то шаблонные движки попросту состу, а люди (при традиционном подходе) переходят к программированию на жабаскрипте. Вот погляди пример
Это всё реализовано много где и лучше и хуже. Например, в GWT, мне кажется, реализовано лучше.
VD>В традиционном подходе вообще нечего этому самому верстальщику дать.
Вот поэтому традиционный мне не нравится, и ваш от него вообще никуда не ушел.
Мне бы хотелось, чтобы верстальщику можно было дать верстать статическую страницу, а фрэйворк умел потом распарсить и генерировать динамическое представление по образцу.
VD>В общем, ты сравниваешь очень разные задачи. НемерлВеб решает задачу создания интерактивного WUI.
Эту задачу уже 10 лет решают. И знаешь почему её не решили? Потому что её решают программисты, которые понятия не имеют о труде верстальщика и верхом совершенства считают как можно более красивое смешивание ХТМЛ кода и биндингов, и у них в голове не умещается, что это просто надо разделить на 2 разных файла. Верстка РСДН идеальное тому подтверждение. Я пытался настроить свои стили и скрипты для РСДН, как делал это для многих сайтов, которыми пользуюсь постоянно — более недружественной верстки я просто никогда не встречал.
Re[16]: Дерево для rsdn.ru созданнео на NemerleWeb
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, avpavlov, Вы писали:
F>>> Кстати, а кто ещё умеет немножко генерить JS? Ну GWT не берём — я его ниасиливаю.
A>>Например, liftweb
VD>Почитал. Про генерацию жабаскрипта ничего не заметил.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, avpavlov, Вы писали:
A>>Задача хорошего шаблонного движка сделать так, чтобы они
VD>Ага. Только одно "но". Речь не идет о шаблонном движке.
Это я уже понял и именно это мне и не нравится
Re[15]: Дерево для rsdn.ru созданнео на NemerleWeb
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, avpavlov, Вы писали:
A>>Примерно такой подход реализован в Викете, хотя по 2 и 3 пунктам там не всё всегда гладко.
VD>С каких пор Викет научился писать клиентский код? Не путаешь ли ты то что Викет умеет генерировать жабаскрипт с возможностью преобразовть код на Яве в клиентский ЯваСкрипт?
А где у меня написано, что Викет умеет клиентский ЯваСкрипт? Я утверждал, что Викет идет по правильному пути с точки зрения разделения HTML и кода. ЛифтВеб умеет клиентский ЯваСкрипт и умеет разделять ХТМЛ и код, так что он дальше всех пошел. Но мне Лифт не нравится из-за своей нестройности, в него пихали всё, до чего дотянулись, получилось очень неприглядно (но концепция, заложенная в нем, мне нравится)
A>>Но главная проблема там, что связывание идет через string id, которые, естественно, не компайл-сэйф. VD>В этом нет ничего естественного. Это — косяк.
Прочитай внимательно, я уже 2 раза писал, что это — косяк.
A>>Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. VD>Ты, видимо, тоже попутал какой-то шаблонный движок (которых 100500) с MVVM-фреймворком. Это как бы настолько разные вещи, что даже сравнивать их не стоит.
Никакая магическая аббревиатура не делает NW уникальным. Сейчас все всё умеют (ну или пытаются) и все у всех всё заимствуют. А называться это в каждом месте может как угодно.
Re[19]: Дерево для rsdn.ru созданнео на NemerleWeb
VD>Я правильно понял, что submit на сервере выполняется? Если так, то я поздравляю тебя. Ты изобрел Asp.Web.Forms образца 2002-го года. Подход признана тупиковым.
АспВебФормс — это такая же мешанина кода и разметки, как NW — значит ли это что вы тоже его изобретаете?
VD>Просто попытайся разобраться в том что такое НемерлВеб. Уверяю тебя ты даже не представляешь насколько он круче.
Я веб разработкой занимался 10 лет — достаточный срок, чтобы понять, что мне не нравится смесь разметки и кода (собственно то, с чем Мамут в тему зашел).
A>>Верстальщик верстает образец дерева, проверяет его на длинных и коротких названиях узлов, проверяет вложенность, раскрытые и закрытые узлы. Парсер парсит HTML и запоминает необходимую структуру, и потом, когда ему передадует модель дерева, генерирует окончательный ХТМЛ по образцу
VD>Это не взлетит просто потому может случиться комбинаторный взрыв. Да и объем кода будет неподъемным.
А может и не случиться.
VD>Короче, тебе нужно для начала понять что такое MVVM.
Новая аббревиатура не делает этот подход чем то мега уникальным. Это как с паттернами — программируешь, программируешь, потом попадается в руки книжка и ты понимаешь, что оказывается, это был синглтон, это фабрика, это билдер и т.д.
Re[17]: Дерево для rsdn.ru созданнео на 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 и оставить только то, что внутри ?
Я размышлял вслух про свой идеал. Думаю, что чисто средствами языка (пусть и мощного, как Немерле) он вряд ли реализуем. Тут скорее важна хорошая поддержка в ИДЕ, но если есть поддержка в ИДЕ, то уже и мощный язык не нужен
Re[24]: Дерево для rsdn.ru созданнео на NemerleWeb
Здравствуйте, 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 для немножечко программиста почти ничего не меняет.
Re[15]: Дерево для rsdn.ru созданнео на NemerleWeb
Здравствуйте, avpavlov, Вы писали:
A>Например, liftweb
Посмотрел по внимательнее. Ничего он не умеет. Там ест убогое апи для представления жабаскрипта в виде оъектов. Не более того.
A>Викет умеет, правда он на Яве и слегка многословно смотрится.
Wicket тоже не умеет.
Вот GWT умеет. Но он ничего не знает про MVVM. Так что в Вебе у НемерлВеб прямых аналогов нет. Есть KnockoutJS и AngularJS, но это жабаскрипт-библиотеки. Совмещение статической типизации и MVVM для Web есть только в ZK Framework. И то не уверен, что у них биндинги проверяются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Дерево для rsdn.ru созданнео на NemerleWeb
Речь то шла об автоматическом преобразовании статически-типизированного языка в жабаскрипт. Кода я пишу код на НемерлВеб я могу вообще не знать жабаскрипт. Ошибки типизации и связывания проверяются во время компиляции. Сам язык в несколько раз более мощный (паттерн-матчинг, алгебраические типы, макросы).
Ну, и не стоит забывать, что это к тому же реализация 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 броузера.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Дерево для rsdn.ru созданнео на NemerleWeb
Здравствуйте, avpavlov, Вы писали:
VD>>С каких пор Викет научился писать клиентский код? Не путаешь ли ты то что Викет умеет генерировать жабаскрипт с возможностью преобразовть код на Яве в клиентский ЯваСкрипт?
A>А где у меня написано, что Викет умеет клиентский ЯваСкрипт?
Это видно в вопросе на который ты отвечал. Тебя спросили какой еще движек умеет генерировать жабаскрипт по коду на другом языке.
A>Я утверждал, что Викет идет по правильному пути с точки зрения разделения HTML и кода.
Ошибочно утверждал.
A> ЛифтВеб умеет клиентский ЯваСкрипт
В таком виде его все имеют. Подход называется — закат солнца вручную.
A>и умеет разделять ХТМЛ и код, так что он дальше всех пошел.
Ты зациклился на этом разделение. Несомненно это хорошо. Но это не единственная переменная в уравнении.
Когда народ задумывал НемерлВеб я предложил использовать подход Лифта, но умные люди (Вольвхаунд) резонно заметил, что это примитивный тупиковый подход не позволяющий существенно упростить и удешевить разработку сложных интерфейсов.
Вольфаунд предложил использовать архитектурный паттерн MVVM, который на тот момент почти нигде (кроме WPF и НокаутаЖС) не был реализован.
Совмещение мощного статически типизированного языка, декларативный биндинга (вместо обработки событий и груды кода), и другие прелести MVVM делают программирование на нем намного более продуктивным.
A>>>Вот тут и есть простор для НемерлеВеб, который мог бы проверять такое связывание в компайл-тайм. VD>>Ты, видимо, тоже попутал какой-то шаблонный движок (которых 100500) с MVVM-фреймворком. Это как бы настолько разные вещи, что даже сравнивать их не стоит.
A>Никакая магическая аббревиатура не делает NW уникальным. Сейчас все всё умеют (ну или пытаются) и все у всех всё заимствуют. А называться это в каждом месте может как угодно.
Ты столкнулся с подходом который ты не понимаешь. Использовать ты его не мог именно по этой причини. Так что обольщайся.
Сейчас у тебя есть два пути. Пойти и разобраться том о чем тебе говорят (MVVM) или окончательно свалиться в паттерн поведения "Блаб-программист" и продолжить самоуверенно спорить о том в чем ничего не понимаешь.
Я бы тебе все же посоветовал первый путь. Изучение нового никогда не бывает лишним.
До тех пор пока ты не разберешься что же такое MVVM спорить с тобой бесполезно. По сему я откланиваюсь. Если ты соизволишь изучить MVVM, то обращайся и я аргуменнтированно покажу тебе почему подход НемерлеВеб так хорош, а все эти твои Кикеты и Лифты — тупиковые технологии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Дерево для rsdn.ru созданнео на NemerleWeb
Здравствуйте, 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>Не нужно знать. Верстальщик делает статическую форму в удобно для него редакторе и проверяет сразу в броузере. А программист потом расставляет биндинги. Причем в хорошем фрэймвореке, верстальщик может вернуться к форме и продолжать править, приэтом расставленные биндинги не должны ему мешать проверять прямо в броузере
Можно название хорошего фреймворка в студию? А то что-то в продакшене я таких не видал...
Re[14]: Дерево для rsdn.ru созданнео на NemerleWeb
Раскажу только свой скромный опыт.
У нас вьюхи на 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. Но считать это чем то супер критичным — хз, не уверен.
Re[15]: Дерево для rsdn.ru созданнео на NemerleWeb
Здравствуйте, 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. Но считать это чем то супер критичным — хз, не уверен.
Я думаю, что на практике, за счет того, что во вьюхи будет попадать больше деталей чуть программисты и вообще не программисты даже больше смогут исправить.
Единственное что — чтобы посмотреть на результат придется скомпилировать и запустить проект. Но не думаю, что это будет критично.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Дерево для rsdn.ru созданнео на NemerleWeb
В смысле нет джаваскрипта? Судя по http://nemerlewebsamples.apphb.com/ он генерирутся? Если так то есть следующие вопросы.
1) Что если надо сделать что-то в джаваскрипте, что нельзя сделать средставами NemerleWeb? Или можно написать все что угодно и это будет скопмилировано в любой javascript?
2) Как быть с джаваскриптовыми библиотеками и компонентами. Например jQuery и его плагины, можно ли их использовать? Ведь написаны тысячи бесплатных и очень качественных джаваскриптовых конролов и компонент, под любые задачи.
3) Можно ли писать код активно взаимодействующий с браузером? Имею в виду подписываться на эвенты браузера, использовать file api, history api. Можно ли писать код специфичный для браузера (например реализовать какой-то воркэраунд для IE8 который много чего не поддеривает?
4) Если наблюдается некая бага в динамической части сайта, то часто способ ее решения это в консоли браузера поиграться с джаваскриптовыми функциями (а я знаю с какими, ведь я их сам писал), и посмотреть, что получается. Как быть в случае немерле веб, смогу ли я с легкостью разобраться со сгенерированными джаваскриптами и поиграться с ними. А если найду баг в джаваскрипте, то легко ли мне будет найти код, который сгенерировал этот джаваскрипт? А если выяснится что бага в генераторе джаваскрипта?
Более философский вопрос.
5) Допустим я решил поменять работу, и на новой работе не используют немерле, но больше традиционные подходы к веб программированию. Смогу ли я применить свой опыт в традиционных проектах? Или придется переучиваться и перестраивать мышление?
Лично я джаваскрипт ненавижу, убогий язык.. И рад бы если бы появилось в вебе что-то более полноценное (статически типизированное, с поддержкой ООП). Но столько на нем всего написано сейчас, что эта мечта кажется из области фантастики.
Re[17]: Дерево для rsdn.ru созданнео на NemerleWeb
Вопросы скорее к авторам библиотеки, но попробую ответить в меру своих знаний.
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 в новую контру. Умный руководитель оценит упрощение и ускорение разработки. Тут как и в любом деле риски против выгоды. Оцениваешь и выбираешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Но если разработать свой кастомный компонент (а Викет в первую очередь компонентно-ориентированный фр-рк), то работать будет. Но поддержка на уровне ИДЕ не появится, на уровне комилятора — тоже. Потому что stringly-typed и на Яве никуда не деться от этого
, прочти что там написано и попытайся понят. Слушай умных людей. Изучай их опыт. Только дурак учится на своих ошибках.
