Как быть с JS-Only библиотеками ?
Неужели оборачивать их в Nemerle аналог.
В Google Web Toolkit таким образом это решается.
Не очень удобно когда нужно это делать вручную с нуля.
Как интегрируется веб дизайнер в этом фреймворке ?
Например, веб дизайнер выдает голый HTML с JS контролями.
Будет ли нужно это все переводить вручную в DSL ?
Здравствуйте, _NN_, Вы писали:
_NN>Как быть с JS-Only библиотеками ? _NN>Неужели оборачивать их в Nemerle аналог.
Ты как-то сам с собой разговариваешь.
_NN>В Google Web Toolkit таким образом это решается. _NN>Не очень удобно когда нужно это делать вручную с нуля.
Так в чем вопрос то? Оборачивай если надо.
_NN>Как интегрируется веб дизайнер в этом фреймворке ?
Веб-дизайнер — это HTML-редактор?
_NN>Например, веб дизайнер выдает голый HTML с JS контролями.
Зачем с JS?
_NN>Будет ли нужно это все переводить вручную в DSL ?
Если у тебя есть статическая верстка, то можешь ее сделать где угодно и потом добавить в нее динамику.
А вообще тот кто занимается мордой должен освоить ДСЛ для описания view и используя предоставляемые программистами VioewModel-ы делать интерфейс. По сути там получается что-то типа ХТМЛ с незначительным количеством конструкций позволяющих биндить VioewModel и рендерить динамический контент.
Погляди примеры http://knockoutjs.com. Вьюх будут чем-то подобным их вьюхам, толко статически типизированными и с Н вместо ЖС в качестве кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Так в чем вопрос то? Оборачивай если надо.
В чем тогда отличие от GWT ?
_NN>>Как интегрируется веб дизайнер в этом фреймворке ?
VD>Веб-дизайнер — это HTML-редактор?
Человек.
_NN>>Например, веб дизайнер выдает голый HTML с JS контролями.
VD>Зачем с JS?
Ну скажем используется JQuery UI.
_NN>>Будет ли нужно это все переводить вручную в DSL ?
VD>Если у тебя есть статическая верстка, то можешь ее сделать где угодно и потом добавить в нее динамику.
VD>А вообще тот кто занимается мордой должен освоить ДСЛ для описания view и используя предоставляемые программистами VioewModel-ы делать интерфейс. По сути там получается что-то типа ХТМЛ с незначительным количеством конструкций позволяющих биндить VioewModel и рендерить динамический контент.
Т.е. человек который создает статическую разметку, сначала создает HTML в его любимом редакторе, а потом вручную переводит в DSL ?
Здравствуйте, _NN_, Вы писали:
VD>>А вообще тот кто занимается мордой должен освоить ДСЛ для описания view и используя предоставляемые программистами VioewModel-ы делать интерфейс. По сути там получается что-то типа ХТМЛ с незначительным количеством конструкций позволяющих биндить VioewModel и рендерить динамический контент. _NN>Т.е. человек который создает статическую разметку, сначала создает HTML в его любимом редакторе, а потом вручную переводит в DSL ?
Имхо, все шаблоны должны быть в html. Как статика, так и для динамического биндинга. Динамически подгружаемые со вставками DSL вроде jquery-template, в том числе и для биндингов. Валидность биндингов должна проверяться в процессе компиляции. А "статику" должен обеспечивать любой существующий фреймворк ASP.NET MVC, NancyFx, хоть WebForms. WUI должен обеспечивать только реактивный UI и не быть зависимым от внешних фреймворков. Подключаться он должен как точка маппинга урлов для методов передачи данных и генерируемого js.
По поводу подключения внешних js тоже пока нет единого мнения. Я считаю, что на уровне языка достаточно дать возможность вставлять в nemerle нетипизированный js код, который будет общаться с внешними либами. Это даст возможность как писать типизированные обертки так и спокойно работать без них.
Сейчас бесполезно гадать, что и как будет. Ибо это будет решать разработчик WUI, все что у нас есть это очень общие идеи, наброски для DSL и прототип компилятора nemerle кода в js.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, _NN_, Вы писали:
VD>>>А вообще тот кто занимается мордой должен освоить ДСЛ для описания view и используя предоставляемые программистами VioewModel-ы делать интерфейс. По сути там получается что-то типа ХТМЛ с незначительным количеством конструкций позволяющих биндить VioewModel и рендерить динамический контент. _NN>>Т.е. человек который создает статическую разметку, сначала создает HTML в его любимом редакторе, а потом вручную переводит в DSL ?
Z>Имхо, все шаблоны должны быть в html. Как статика, так и для динамического биндинга. Динамически подгружаемые со вставками DSL вроде jquery-template, в том числе и для биндингов. Валидность биндингов должна проверяться в процессе компиляции. А "статику" должен обеспечивать любой существующий фреймворк ASP.NET MVC, NancyFx, хоть WebForms. WUI должен обеспечивать только реактивный UI и не быть зависимым от внешних фреймворков. Подключаться он должен как точка маппинга урлов для методов передачи данных и генерируемого js.
А разве WUI не претендовал на замену всему ?
Выглядит конечно более разумно на первый взгляд, но насколько тогда нужен сам WUI ?
Тогда можно взять C# и добавить к нему метаатрибуты для генерации.
Z>По поводу подключения внешних js тоже пока нет единого мнения. Я считаю, что на уровне языка достаточно дать возможность вставлять в nemerle нетипизированный js код, который будет общаться с внешними либами. Это даст возможность как писать типизированные обертки так и спокойно работать без них.
Это похоже на путь GWT, там можно писать обертки и генерировать js.
Но мне он не понравился, слишком много кода писать для простых действий.
Да и Java
Z>Сейчас бесполезно гадать, что и как будет. Ибо это будет решать разработчик WUI, все что у нас есть это очень общие идеи, наброски для DSL и прототип компилятора nemerle кода в js.
Я подумываю заняться разработкой.
Нужно только уточнить насколько стоит этим заниматься и не проще взять что-то другое. С другой стороны что "другое" можно взять ?
_NN>Я подумываю заняться разработкой. _NN>Нужно только уточнить насколько стоит этим заниматься и не проще взять что-то другое. С другой стороны что "другое" можно взять ?
websharper, не?
Здравствуйте, _NN_, Вы писали:
_NN>Я подумываю заняться разработкой. _NN>Нужно только уточнить насколько стоит этим заниматься и не проще взять что-то другое. С другой стороны что "другое" можно взять ?
Я пробовал скрестить knockoutjs и haXe, но понял что для нормального секрещивания нужно забираться в дебри макросов haXe. Без нормального PM-а и квазицитат мне показалась задача слабоподъемной.
Здравствуйте, _NN_, Вы писали:
VD>>Так в чем вопрос то? Оборачивай если надо.
_NN>В чем тогда отличие от GWT?
Я GWT не видел. Судя по описанию GWT — это просто генерилка жабаскрипта по Жабе.
Мы же с Вольфхаундом говорили о реактивном фрэмворке позволяющем свести программирование к минимум. В нашем варианте в представлении кода почти нет. В основном биндинг.
Короче, у нас генерация жабаскрипта — это всего лишь подфича. У GWT — это основная фича.
VD>>Зачем с JS? _NN>Ну скажем используется JQuery UI.
Вот весь смысл этого фрэймворка в том, чтобы не надо было писать вообще никакого кода, и уж тем более на жабаскрипте.
Если есть какие-то внешние библиотеки, то нужно их инкапсулирвоать в свои контролы с типизированным интерфейсом и использовать их через биндинг.
Писать же код нужно только в модели представления. В самом представлении кода быть не должно. Максимум простенькие инлайн-вставки.
Дык сам ДСЛ — это и разновидность ХМЛ-я. Так что он все будет делать в своем любимом редакторе. Просто его придется обучить тому какие теги что значат, и тому как делать биндинг.
Если будет комплит (что вполне возможно поддержать), то он будет выбирать биндинг из списка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>Сейчас бесполезно гадать, что и как будет.
Вот это, пожалуй, самая здравая мысль. Идея есть. Прототип есть. То что проект можно реализовать сомнений нет. А детали реализации будут 100 раз изменяться по ходу углубления в детали. Так бывает всегда и везде. Так что нужно не думать и гадать, а браться и делать. Жизнь сама подскажет лучшие решения.
ЗЫ
Не подумай, что я согласился с тем, что идея пихать жабаскрипт куда попало — хорошая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _NN_, Вы писали:
_NN>А разве WUI не претендовал на замену всему ?
В WUI главное то что ты опустил — Nemerle...Reactive.
Первое (Nemerle) дает нам возможность забыть о разделении на серверный код написанный на одном языке, и на клиентский на другом (скриптовом). Так же он позволяет автоматизировать все рутинные операции и сделать решение почти декларативным. Reactive позволяет сделать полностью декларативным описание того самого WUI. Это делается за счет того, что представление практически не содержит кода.
_NN>Выглядит конечно более разумно на первый взгляд, но насколько тогда нужен сам WUI ?
Выглядит как раз не разумно. Никакая статика не нужна. Если у нас есть динамические "шаблоны", то сделать их статическими (т.е. отрабатывающими на сервере) уже дело техники.
Никакого джейвери в чистом виде тоже быть не должно. Весь код шаблонов должен статически проверяться. На клиенте возможно и получится использовать какие-то готовые решения вроде джейкверевого шаблонизатора или шаблонизатора кнокаута, но это уже детали реализации. О них пользователь (прикладной программист) знать не должен.
Я бы вообще не называл это шаблонизатором. Это ДСЛ представлений. В нем главное — это биндинг, а не код. Код там должен быть очень ограниченным. И по возможности его нужно так же помещать в контролы с биндингом, а не писать в прикладных решениях.
_NN>Тогда можно взять C# и добавить к нему метаатрибуты для генерации.
Тогда ты никогда не получишь того о что можно добиться в Nemerle.WUI.Reactive. Ты получишь еще один убогий фрэмворк похожий на 100500 таких же убогих фрэймворков. Повышать производительность струда по сравнению с ними он не будет. А по сравнению с применением того же кнокаута ты еще и проиграешь. Учитывая не высокую популярность самого немерла с огромной вероятностью можно сказать, что фрэмворк никого не заинтересует.
Z>>По поводу подключения внешних js тоже пока нет единого мнения. Я считаю, что на уровне языка достаточно дать возможность вставлять в nemerle нетипизированный js код, который будет общаться с внешними либами. Это даст возможность как писать типизированные обертки так и спокойно работать без них. _NN>Это похоже на путь GWT, там можно писать обертки и генерировать js.
Это доже в 100 раз хуже. Это похоже на дырявую абстракцию. В этом смысл нет вообще.
Есть смысл полностью запретить использование жабаскрипта (и других языков) в моделе представления и самой модели.
Для совместимости со внешними жабаскриптовыми библиотеками имеет смысл дать возможность писать кастом-контролы которые будут инкапсулировать жабаскрипт. Кастом-контрол — это типизированный интерфейс в виде контророла Nemerle.WUI.Reactive, но содержащий в своих кишках произвольный жабаскрипт и хмл/хтмл. Суть его заключается в том, что у такого контрола (тега) будут четко прописан интерфейс в виде атрибутов тега и биндингов на них.
Кастом-контролы можно будет писать как в нетипизированном виде, так и в типизированном (на подмножетсве немерла). Для типизированного варианта внешнюю жабасктиптовую библиотеку придется обернуть типизированным интерфейсом на подобии вот этой обертки для массива жабаскрипта.
_NN>Нужно только уточнить насколько стоит этим заниматься и не проще взять что-то другое. С другой стороны что "другое" можно взять ?
Проще — возьми. За одно расскажешь остальным чем это проще и что это дает.
Мое мнение однозначное — Nemerle.WUI.Reactive мог бы стать киллер-приложением для Н. Он явно будет востребован и обладает вполне осязаемой крутостью. Аналогов в типизированном мире нет и не ясно когда появятся (если я ничего не просмотрел). Ну, разве что UrWeb (или как там его?), но это явно академический проект который вряд ли выйдет использовать на практике.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
