Вкратце — это продолжение идеи WUI.Reactive, только переписанное практически с нуля. Удалось создать достаточно мощный транслятор Nemerle -> Javascript, правда немного заточенный под конкретные MVVM нужды. Если кто не знает, как работает MVVM в вебе, то советую посмотреть на http://knockoutjs.com/. Эта библиотека сейчас как раз и используется для биндингов.
Теоретически ограничения транслятора упираются только в BCL, который, конечно никто не будет дублировать. Практически, проект даже не на стадии альфа, так что о полноте возможностей проебразования говорить пока рано. Однако матчинг, string interpolation, и прочие вкусности работают.
Также была добавлена возможность общаться с сервером в такой манере:
SomeClientSideFunction(user) {
server.SaveUser(user, result => {
//Do something with result
});
}
Сервер описан во вложенном классе:
class Server {
SaveUser(user : User) : string {
db.Users.Update(user);
$"User $(user.Name) succcessfully updated!"
}
}
Достаточно в модели представления объявить вложенный класс с именем Server, так сразу появляется доступ к полю server с нужными методами, у которых добавляется параметр-коллбек. На данном этапе это единственная конвенция, но можно будет сделать и другие, например ИмяМоделиServer
Пока это всё. За Roadmap я ещё даже не садился, но планов выше крыши.
Одному работать очень тяжело, три недели практически безвылазно программировал, так что надеюсь, что кто-то ещё заинтересуется.
Здравствуйте, VladD2, Вы писали:
VD>Это называется — протекающая абстракция.
Не-а, протекающая абстракция это когда тебе нужно сгенерить какой-то джаваскрипт, но фреймворк на такое (из-за архитектурных ограничений) не способен, а кастомный джаваскрипт вставлять не дает по идеологическим причинам.
Здравствуйте, dotneter, Вы писали:
D>Это почему же? Подобный транслятор можно использовать где угодно, хватило бы фантации, хоть с note.js, хоть пиши мобильные приложения с phonegap или расширения для браузеров.
Всё что ты перечислил это и есть разные контексты, для каждого из которых надо генерировать "особенный" джаваскрипт.
D>По моему универсальное решение это, беру файл test.n натравливаю на него n2js.exe получаю на выходи test.js добавлю зависимость от какой то общей либы nemerle.js и все, у меня вся логика test.n работает на джаваскрипте. Ну и желательно что бы не было какой либо низкоуровневой зависимости от стороних фреймворков, что бы они поставлялись в виде отдельных необязательных либах.
Это утопия. Окружение джаваскрипта и .NET слишко сильно различаются, чтобы можно было в общем случае получить test.js из test.n. Для того, чтобы код в test.js корректно исполнялся, тебе нужно написать нужную обвязку для того контекста, в котором test.js будет запущен.
Кстати, BCL — это тоже грубо говоря "низкоуровневая зависимость от стороннего фреймворка".
Почти доделал макрос для предсавлений, который разбирает все выражения внутри вьюхи и генерирует валидную knockoutjs разметку.
Выглядит это примерно так:
То есть пишем по привычке, как будто просто хотим подставить значение, а на деле генерируются нужные аттрибуты и теги. Всё это дело проверяется компилятором, так что большинство ошибок отлавливается в компайл-тайм.
Пока не решил, как записывать выражения вроде:
Здравствуйте, ionoy, Вы писали:
I>Обновили сайт. I>Также теперь показываются как исходники как выбранного туториала, так и главной страницы.
Ещё было бы неплохо на github ссылку на сайт оставить, а то там старая...
Хотелось бы видеть транслятор в виде отдельного самодостаточного проэкта, хотя бы в виде утилиты командной строки. Имхо веб-фреймворк для Немерла нужен полтора человеку, а вот альтернатива js может быть интересна и для далеких от .net
Здравствуйте, ionoy.
Вы писали: I> Я про то, что применять подобный транслятор можно только в некотором контексте, например, скрипт для страницы.
Это почему же? Подобный транслятор можно использовать где угодно, хватило бы фантации, хоть с note.js, хоть пиши мобильные приложения с phonegap или расширения для браузеров.
I> Собственно, ничего не мешает сделать утилиту, которая бы вызывалась из коммандной строки. Только надо определится, что мы хотим иметь на выходе, потому что универсального решения, имхо, не существует.
По моему универсальное решение это, беру файл test.n натравливаю на него n2js.exe получаю на выходи test.js добавлю зависимость от какой то общей либы nemerle.js и все, у меня вся логика test.n работает на джаваскрипте. Ну и желательно что бы не было какой либо низкоуровневой зависимости от стороних фреймворков, что бы они поставлялись в виде отдельных необязательных либах.
Здравствуйте, catbert, Вы писали:
VD>>Это называется — протекающая абстракция. C>Не-а, протекающая абстракция это когда тебе нужно сгенерить какой-то джаваскрипт, но фреймворк на такое (из-за архитектурных ограничений) не способен,
Значит нужно дорабатывать фреймворк.
Но у меня есть очень большие сомнения, что оно нужно не по тому, что так хочется, а по тому, что оно действительно нужно.
C>а кастомный джаваскрипт вставлять не дает по идеологическим причинам.
Нет. Это именно протекающая абстракция.
То, что ты хочешь всё равно, что хотеть писать посреди C# на х86ом ассемблере.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Аноним, Вы писали:
А>не понравилось что много кода
В смысле много? (много кода не бывает, бывает наоборот мало и глючного).
Есть идеи как сделать короче?
Re[11]: Сделал прототип Веб фреймворка для Немерле
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, ionoy, Вы писали:
I>>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи? WH>
WH>view model Introduction
WH>{
WH> FirstName : string;//Свойства которые можно читать/писать.
WH> LastName : string;//Система автоматом отслеживает их изменения.
WH> FullName : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
WH> //Обновляется автоматически при изменении любого из значений от которого зависит.
WH> CapitalizeLastName() : void
WH> {
WH> LastName = LastName.ToUpper();
WH> }
WH>}
WH>
Хм, ну за исколючением небольших деталей так оно и есть.
Свойство — observable значение
Свойство, где объявлен только get — вычисляемый observable
Поле — обычное значение, которое не отслеживает изменений
Замена class на view model конечно не помешала бы, но для этого слишком много городить надо.
Здравствуйте, Аноним, Вы писали:
А>Как один из вариантов. А>В действительности часто бывает что не значительную часть данных надо передать. Кроме того можно ненароком передать ссылку на объект содержащий конфиденциальные данные и они передадутся на клиента.
А>вообщем есть 4 варианта А>сериализируемые А>несереализируемые А>только клиент А>только сервер
Дело не в том, что мы хотим передать, а в том, что сервер примет. Если на сервере данные будут биндится к модели, у которой есть поле Password, то мы никаким образом не сможем помешать это поле обновить. (кроме, конечно, явного указания, что это поле не должно биндится). Совсем не важно, есть ли в JS модели поле Password или нету.
Правильное решение имхо исходит из самого фреймворка MVVM. На сервере есть модель User со всеми нужными полями. На клиенте у нас есть UserInfoViewModel, у которого есть только Age и AvatarUrl. Экшн сервера выглядит примерно так:
public UpdateUserInfo(model : UserInfoViewModel) : ActionResult
{
var user = Map.[User](model);
db.Update(user);
...
}
Здравствуйте, VladD2, Вы писали:
VD>Теперь надо бы заняться типизацией представлений (чтобы и в них код преобразовывался из немерлового).
Для начала надо решить, как будут описываться представления, через XML макрос или каким-то другим способом. Если, через макрос, то его надо допиливать, так как у него есть ограничения.
Дальше надо решить, каким образом описывать биндинги. У меня была идея на подобие такой:
Объект bind генерируется макросом, так что мы получаем интеллисенс и прочее.
Хорошо бы ещё каким-то образом устранить необходимость скобок для простых выражений, как это сделано в Рейзоре.
VD>Так же надо бы сделать более пушистые тесты, а то на примитивных не видна мощь.
Предлагайте тему, попробую реализовать. Мне самому интересно как это дело будет себя вести в боевых условиях.
VD>Что касается АСП-хостинга, то можно на РСДН-е захоститься.
Было бы отлично. Если это возможно, то напиши, пожалуйста, в личку как получить доступ.
Здравствуйте, ionoy, Вы писали:
I>Если получиться с РСДН хостингом, то в субботу/воскресенье выложу. Если нет, постараюсь найти в ближайшие дни что-нибудь подешевле и зарегить там.
А что же там не получится? Конечно получится.
У тебя есть скайп Ziaw? Постучись к нему. У него есть нужны права и опыт. Если еще и время найдется, он тебе обязательно поможет в этом вопросе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Для начала надо решить, как будут описываться представления, через XML макрос или каким-то другим способом.
Дык, решай. Это и есть дизайн. Проект твой, тебе и решать.
I>Если, через макрос, то его надо допиливать, так как у него есть ограничения.
Я, думаю, что однозначен надо делать через макрос. Вопрос только какой, макрос. Нужно чтобы представление было статически типизировано (чтобы ошибки выявлялись во время компиляции, и чтобы интелисенс был).
I>Дальше надо решить, каким образом описывать биндинги. У меня была идея на подобие такой:
I>
Зачем здесь js?
I>Объект bind генерируется макросом, так что мы получаем интеллисенс и прочее.
Его и без объекта можно получить. У представления должны быть реактивные пропертя к которым можно биндиться. Чем меньше будет мусора, тем лучше.
I>Хорошо бы ещё каким-то образом устранить необходимость скобок для простых выражений, как это сделано в Рейзоре.
Думаю, с этим особых проблем не будет. Просто после @нужно скармливать код парсеру немерла и тот сам съест столько сколько сможет. Если что, доработаем напильником что надо.
VD>>Так же надо бы сделать более пушистые тесты, а то на примитивных не видна мощь. I>Предлагайте тему, попробую реализовать. Мне самому интересно как это дело будет себя вести в боевых условиях.
Блоги для РСДН
А так, что-нить с серверным кодом. Чтобы было видно как вызываетется серверна сторона, как ей данные (типизированные) передаются, и как результат передается обратно.
VD>>Что касается АСП-хостинга, то можно на РСДН-е захоститься. I>Было бы отлично. Если это возможно, то напиши, пожалуйста, в личку как получить доступ.
Ну, админский доступ раздавать всем я не могу. Он есть у Алекса Зимина (Ziaw). Свяжись с ним по скайпу. Думаю, он тебе поможет. Да и админ из него намного более проффесиональный, чем из меня.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ionoy, Вы писали:
I>>Если, через макрос, то его надо допиливать, так как у него есть ограничения. VD>Я, думаю, что однозначен надо делать через макрос. Вопрос только какой, макрос. Нужно чтобы представление было статически типизировано (чтобы ошибки выявлялись во время компиляции, и чтобы интелисенс был).
Видимо придётся брать XML за основу и дополнять его нужными фишками по мере необходимости.
I>>
VD>Зачем здесь js?
Ассемблерная вставка А если серъёзно, то нужна возможность иногда откатиться в чистый ЖС. Посмотри, например, третий туториал. Там я теоретически мог бы сделать обёртку для Sammy, и всё описать на Немерле. Но это взяло бы много времени и с каждым изменением API мне пришлось бы допиливать свою обёртку. Короче, без подобных лазеек некоторые вещи будет очень сложно сделать.
VD>Его и без объекта можно получить. У представления должны быть реактивные пропертя к которым можно биндиться. Чем меньше будет мусора, тем лучше.
Покажи код, каким ты себе его представляешь.
VD>Блоги для РСДН
В блогах мало интерактива, там преимущества MVVM не так заметны. Такой проект хорошо делать, когда фреймворк уже взрослый, чтобы показать как на нём строится архитектура приложения, работа с БД и прочее.
VD>А так, что-нить с серверным кодом. Чтобы было видно как вызываетется серверна сторона, как ей данные (типизированные) передаются, и как результат передается обратно.
Кстати, теоретически должны работать Computation Expressions, надо только написать обёртку для аякса.
VD>Ну, админский доступ раздавать всем я не могу. Он есть у Алекса Зимина (Ziaw). Свяжись с ним по скайпу. Думаю, он тебе поможет. Да и админ из него намного более проффесиональный, чем из меня.
ОК.
Здравствуйте, ionoy, Вы писали:
I>Видимо придётся брать XML за основу и дополнять его нужными фишками по мере необходимости.
Наверно.
I>Ассемблерная вставка А если серъёзно, то нужна возможность иногда откатиться в чистый ЖС. Посмотри, например, третий туториал. Там я теоретически мог бы сделать обёртку для Sammy, и всё описать на Немерле. Но это взяло бы много времени и с каждым изменением API мне пришлось бы допиливать свою обёртку. Короче, без подобных лазеек некоторые вещи будет очень сложно сделать.
Это называется — протекающая абстракция. До добра подобное не доведет. Сейчас тебе кажется, что это возможность что-то сделать проще, но ты просто закладываешь грабли на будущее, чтобы потом вдоволь по ним находиться.
VD>>Его и без объекта можно получить. У представления должны быть реактивные пропертя к которым можно биндиться. Чем меньше будет мусора, тем лучше. I>Покажи код, каким ты себе его представляешь.
Он должен быть таким же как в твоих исходных примерах, но с учетом того, что это будет код на Немерле.
I>В блогах мало интерактива, там преимущества MVVM не так заметны.
Это как сделать. В прочем, я просто прикалывюсь. Просто нам они давно нужны, но мы их никак не доделаем.
I>Такой проект хорошо делать, когда фреймворк уже взрослый, чтобы показать как на нём строится архитектура приложения, работа с БД и прочее.
+1
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dotneter, Вы писали:
D>Хотелось бы видеть транслятор в виде отдельного самодостаточного проэкта, хотя бы в виде утилиты командной строки. Имхо веб-фреймворк для Немерла нужен полтора человеку, а вот альтернатива js может быть интересна и для далеких от .net
Что подразумевается, под самодостаточным транслятором? Как ни крути, придётся ставить его в какие-то рамки. 1 в 1 приложение .NET невозможно в общем случае привести к ЖС, как минимум из-за того, что в джаваскрипте нет BCL.
Сейчас проект умеет брать заданный класс и строить по нему ЖС код. Но если встечается вызов незнакомого метода или ссылка на незнакомый класс, то он просто оставит всё как есть. Т.е. xs.Where(...).Select(...) волшебным образом не транслируется, придётся вручную реализовывать LINQ. Ну и так далее.
Короче, как ни старайся, штука в любом случае будет ограничена, поэтому надо определится с областью применения и реализовать только то, что нужно в этой области.
Здравствуйте, ionoy, Вы писали:
I>Короче, как ни старайся, штука в любом случае будет ограничена, поэтому надо определится с областью применения и реализовать только то, что нужно в этой области.
Ну я так понимаю сделать что-то вроде Script#.
Здравствуйте, fddima, Вы писали:
I>>Короче, как ни старайся, штука в любом случае будет ограничена, поэтому надо определится с областью применения и реализовать только то, что нужно в этой области. F> Ну я так понимаю сделать что-то вроде Script#.
Что и требовалось доказать. Штука достаточно ограниченная и имеет только одну область применения.
Здравствуйте, ionoy.
Вы писали:
I> Здравствуйте, fddima, Вы писали: I>>>Короче, как ни старайся, штука в любом случае будет ограничена, поэтому надо определится с областью применения и реализовать только то, что нужно в этой области. F>> Ну я так понимаю сделать что-то вроде Script#. I> Что и требовалось доказать. Штука достаточно ограниченная и имеет только одну область применения.
А какие тут еще могут быть области применения кроме как заменить js на что нибудь нормальное? И что значит ограниченная?
Здравствуйте, dotneter, Вы писали:
D>А какие тут еще могут быть области применения кроме как заменить js на что нибудь нормальное? И что значит ограниченная?
Я про то, что применять подобный транслятор можно только в некотором контексте, например, скрипт для страницы.
Собственно, ничего не мешает сделать утилиту, которая бы вызывалась из коммандной строки. Только надо определится, что мы хотим иметь на выходе, потому что универсального решения, имхо, не существует.
Конкретно сейчас мы получаем классы для работы с MVVM, но убрать обёртки ko.observable — это не проблема.
Здравствуйте, dotneter, Вы писали:
D>Здравствуйте, ionoy. D>Вы писали:
D>В первом приближании BCL и не нужен. А нужна только возможность генерировать js из всех конструкций языка, псюс делать обертки над библиотеками js.
Cейчас, по идее, должны обрабатываться практически любые конструкции языка, так как трансляция идёт из типизированного представления (TExpr), которое очень низкоуровневое и никаких сложных вещей не содержит.
Другое дело, что пока это мало тестировалось, поэтому наверняка некоторые вещи остались нереализованными. Также не сделаны такие вещи как наследование, дженерики и т.д. В контексте MVVM это не нужно, поэтому я пока даже не запаривался по этому поводу.
Насчёт обёрток надо подумать, каким образом лучше их оформить. Каждая обёртка должна быть привязана к конкретной версии библиотеки, иначе могут быть конфликты. То есть, нужно сохранять некий модуль класс немерле + файл JS.
Здравствуйте, ionoy.
Вы писали:
I> Здравствуйте, dotneter, Вы писали: D>>Это почему же? Подобный транслятор можно использовать где угодно, хватило бы фантации, хоть с note.js, хоть пиши мобильные приложения с phonegap или расширения для браузеров. I> Всё что ты перечислил это и есть разные контексты, для каждого из которых надо генерировать "особенный" джаваскрипт.
Чем он особенный? Логика то как раз в том что js везде одинаковый и один транслятор можно использовать везде где есть js. D>>По моему универсальное решение это, беру файл test.n натравливаю на него n2js.exe получаю на выходи test.js добавлю зависимость от какой то общей либы nemerle.js и все, у меня вся логика test.n работает на джаваскрипте. Ну и желательно что бы не было какой либо низкоуровневой зависимости от стороних фреймворков, что бы они поставлялись в виде отдельных необязательных либах. I> Это утопия. Окружение джаваскрипта и .NET слишко сильно различаются, чтобы можно было в общем случае получить test.js из test.n.
Вы зачем то постаянно отталкиваетесь от .net, хотя нужно отталкиватся от js. Представте я написал какой то код на js, зачем мне в нем что то нужно от .net? Правильно .net там вообще не нужен. И задача у меня будет написать точно такой же код использую Nemerle и в нем мне .net тоже не нужен. I>Для того, чтобы код в test.js корректно исполнялся, тебе нужно написать нужную обвязку для того контекста, в котором test.js будет запущен.
Если под контектом вы понимаете api, то да, конечно мне нужно будет использовать статическую обертку над апи js, что бы была возможность его вызывать. Хотя использую позднее связывания, можно обойтись и без этого, но тут тогда теряется весь профит от перехода. I> Кстати, BCL — это тоже грубо говоря "низкоуровневая зависимость от стороннего фреймворка".
Какие конкретные классы в BCL вам нужны что бы транслировать в js?
Здравствуйте, ionoy, Вы писали:
I>Почти доделал макрос для предсавлений, который разбирает все выражения внутри вьюхи и генерирует валидную knockoutjs разметку.
Комплит и хинты работают? I>Пока не решил, как записывать выражения вроде: I>
Здравствуйте, VladD2, Вы писали:
VD>Комплит и хинты работают?
Тут мне видимо понадобится помощь. Хинты работают, но разъезжаются. И видимо по этой же причине не работает комплит. Я там просто очень сильно всё перелопатил, и пока ещё не успел занятся локейшенами.
I>>Так что сейчас там грязный хак, который основан на том, что несколько одинаковых атрибутов объединяются в один со значениями разделёнными запятыми. VD>В чем проблема? Зачем какие-то хаки?
Суть в том, что мне одним выражением надо задать три свойства. Как сделано сейчас:
data-bind атрибуты это просто текстовые значения, они никак не парсятся, только в самом конце объединяются в один атрибут. А нужно сделать что-то вроде:
<select options="$AvailableMeals.Options(s.Meal, //"value: Meal" -- Значение 's' приходит из цикла
meal => meal.MealName)" /> //optionsText: 'MealName'
Это всё, конечно, очень условно, но проблему отражает.
VD>Еще логично было бы вместо ":" использовать "=" в качестве разделителя.
А оно так и есть, там где используется ":", это текстовые атрибуты на данный момент.
Здравствуйте, ionoy, Вы писали:
I>Тут мне видимо понадобится помощь. Хинты работают, но разъезжаются. И видимо по этой же причине не работает комплит. Я там просто очень сильно всё перелопатил, и пока ещё не успел занятся локейшенами.
Когда парсишь подвыражения (компилятором), надо корректно задавать начальный локешон. Тогда все будет ОК.
I>Суть в том, что мне одним выражением надо задать три свойства. Как сделано сейчас: I>
I>data-bind атрибуты это просто текстовые значения, они никак не парсятся, только в самом конце объединяются в один атрибут. А нужно сделать что-то вроде: I>
I><select options="$AvailableMeals.Options(s.Meal, //"value: Meal" -- Значение 's' приходит из цикла
I> meal => meal.MealName)" /> //optionsText: 'MealName'
I>
Что-то как-то сложнее оригинала.
И что это дело означает? Что за Options? Что за s?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>><select options="$AvailableMeals.Options(s.Meal, //"value: Meal" -- Значение 's' приходит из цикла I>> meal => meal.MealName)" /> //optionsText: 'MealName' I>>[/code]
VD>Что-то как-то сложнее оригинала.
VD>И что это дело означает? Что за Options? Что за s?
Этого ничего не будет, конечно. Я просто пытался проиллюстрировать проблему.
Мы делаем коллекцию option из AvailableMeals. Для каждого option, нам надо определить 1. отображаемый текст 2. значение. По умолчанию оба выставляются в то, что содержится внутри тэга <option>. В данном случае текст должен браться из поля MealName. Псевдокод примерно такой:
Для того, чтобы в разметке получить интеллисенс для MealName, макрос должен знать из какой коллекции берётся текущее значение. Поэтому meal => meal.MealName (повторюсь, это только иллюстрация).
Две новости:
1. К проекту присоединился NN, будем развивать фреймворк и параллельно делать большой сэмпл проект
2. Зарегили бесплатный хостинг, можно посмотреть сэмплы вживую http://user1663.netfx45lab.discountasp.net/
Здравствуйте, VladD2, Вы писали:
I>>2. Зарегили бесплатный хостинг, можно посмотреть сэмплы вживую http://user1663.netfx45lab.discountasp.net/ VD>Как-то без исходников и пояснений это все не о чем.
Уже почти доделана поддержка встраевамых шаблонов. Как только будет более менее окончательный вариант, то можно будет написать небольшую статью-описание.
Здравствуйте, ionoy, Вы писали:
I>Две новости: I>1. К проекту присоединился NN, будем развивать фреймворк и параллельно делать большой сэмпл проект I>2. Зарегили бесплатный хостинг, можно посмотреть сэмплы вживую http://user1663.netfx45lab.discountasp.net/
есть просьба от web-танкистов. что нужно прочитать, чтобы понять, как с этим работать после winforms?
Когда в голове будет чёткое понимание, что такое MVVM в вебе и как его использовать, то можно начинать смотреть исходники сэмплов нашего фреймворка. Это, собственно, те же самые туториалы, только переведённые на Немерле. АПИ ещё далеко не окончательный, так что на него не стоит опираться, но уже как минимум можно посмотреть, как это всё дело работает.
Здравствуйте, Аноним, Вы писали:
А>Скрипт выполняется на клиенте?
Да, на сервере генерируется HTML/Javascript, выполняются они на клиенте.
A>Процедуры валидации есть?
Смотря что подразумевается под валидацией. Если валидность введённых данных (required поля, длина строки и тд), то нет, встроенных механизмов пока нет. Но:
1. Никто не мешает использовать общедоступные механизмы, например, jquery.validation, DataAnnotations и т.д.
2. Очевидно надо будет сделать встроенную валидацию, однако это далеко не на первом месте
A>Темы будут?
Опять же, смотря что под ними подразумевается. Контролов то у нас нет, чистый HTML.
Здравствуйте, ionoy, Вы писали:
I>Уже почти доделана поддержка встраевамых шаблонов.
Что значит "встраиваемых"?
I>Как только будет более менее окончательный вариант, то можно будет написать небольшую статью-описание.
Это дело.
ЗЫ
Было бы здорово подумать над процессом создания вьюх и контролов. Под контролами я понимаю некие повторно испоьзуемые вьюхи которые могут использоваться как отдельные элементы управления.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Добавил показ исходников и дописал движок представлений. Теперь весь рендеринг статически типизирован. (пока кроме options) I>http://user1663.netfx45lab.discountasp.net/
Исходники лучше показывать через prettify, там есть немерловая раскраска.
Здравствуйте, Аноним, Вы писали:
А>не понравилось что много кода
Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?
Здравствуйте, VladD2, Вы писали: VD>Что значит "встраиваемых"?
Наверное слово "встраивамый" здесь лишнее. Это обыкновенные шаблоны привязанные к моделям.
Сейчас это выглядит так:
[JsModel]
public class SeatReservation
{
public Name : string { get; set; }
public Meal : Meal { get; set; }
public Root : ListsAndCollectionsViewModel { get; set; }
[Html]
public EditTemplate() : string {
<#
<div>
<td><input value="$(Name)" /></td>
<td><select options="$(Root.AvailableMeals)" data-bind="value: Meal" data-bind="optionsText: MealName"></select></td>
<td>$(FormattedPrice)</td>
<td><a href="#" click="$(Root.RemoveSeat)">Remove</a></td>
</div>
#>
}
}
[ViewModel]
public partial class ListsAndCollectionsViewModel
{
....
public Seats : List[SeatReservation] { get; set; }
[Html]
public View() : string {
<# <div>
<h2>Your seat reservations (<span>$(Seats.Count())</span>)</h2>
<div $(Template(Seats, _.EditTemplate))></div>
</div> #>
}
}
VD>Было бы здорово подумать над процессом создания вьюх и контролов. Под контролами я понимаю некие повторно испоьзуемые вьюхи которые могут использоваться как отдельные элементы управления.
В принципе шаблоны должны решать эту задачу, ведь никто не мешает шарить их между разными MVVM страницами.
Можно, например, сделать модель содержащюю только шаблон, без данных. А можно сделать модель TextBox и хранить в поле Value текущее значение. Правда его придётся доставать оттуда перед сохранением на сервер, но это небольшая проблема.
Здравствуйте, ionoy, Вы писали:
I>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?
view model Introduction
{
FirstName : string;//Свойства которые можно читать/писать.
LastName : string;//Система автоматом отслеживает их изменения.
FullName : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
//Обновляется автоматически при изменении любого из значений от которого зависит.
CapitalizeLastName() : void
{
LastName = LastName.ToUpper();
}
}
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Сделал прототип Веб фреймворка для Немерле
От:
Аноним
Дата:
22.08.12 10:20
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, ionoy, Вы писали:
I>>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?
view model Introduction
{
FirstName : string;//Свойства которые можно читать/писать.
LastName : string;//Система автоматом отслеживает их изменения.
FullName : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
//Обновляется автоматически при изменении любого из значений от которого зависит.
CapitalizeLastName() : void
{
LastName = LastName.ToUpper();
}
}
Думаю тут лучше будет
property FirstName: string;
server FirstName: string;
client FirstName: string;
потому что часть значений не должна ходить между сервером и клиентом
Re[11]: Сделал прототип Веб фреймворка для Немерле
Здравствуйте, WolfHound, Вы писали:
I>>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи? WH>
WH>view model Introduction
WH>{
WH> FirstName : string;//Свойства которые можно читать/писать.
WH> LastName : string;//Система автоматом отслеживает их изменения.
WH> FullName : string { FirstName + " " + LastName } //Вычислимое свойство. Можно только читать.
WH> //Обновляется автоматически при изменении любого из значений от которого зависит.
WH> CapitalizeLastName() : void
WH> {
WH> LastName = LastName.ToUpper();
WH> }
WH>}
WH>
Насколько я понимаю, в первом немерле для этого нужно писать свой парсер и свою интеграцию.
Re[10]: Сделал прототип Веб фреймворка для Немерле
Здравствуйте, ionoy, Вы писали:
I>Что конкретно каждется лишним? Там много ненужных юзингов, которые можно удалить хоть сегодня, также можно будет избавится от аттрибутов в угоду соглашениям. У вас есть ещё какие-то идеи?
Небери в голову. Это какой-то "доброжелатель". В суть не въехал, а настроение плохое сутра.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Сделал прототип Веб фреймворка для Немерле
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, VladD2, Вы писали: VD>>Что значит "встраиваемых"? I>Наверное слово "встраивамый" здесь лишнее. Это обыкновенные шаблоны привязанные к моделям.
Вот привязка к модели — это, на мой взгляд, не очень правильно.
I>Сейчас это выглядит так:
Как-то вложенность представления в модель представления выглядит странно. Пока не могу сказать плохо ли это. Но решение неожиданное, как минимум.
I>В принципе шаблоны должны решать эту задачу, ведь никто не мешает шарить их между разными MVVM страницами. I>Можно, например, сделать модель содержащюю только шаблон, без данных. А можно сделать модель TextBox и хранить в поле Value текущее значение. Правда его придётся доставать оттуда перед сохранением на сервер, но это небольшая проблема.
Я тут имею в виду, что в таких контролах может быть произвольный код превращающийся в произвольный жабаскрипт.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Сделал прототип Веб фреймворка для Немерле
От:
Аноним
Дата:
22.08.12 12:12
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Не бери в голову. Это какой-то "доброжелатель". В суть не въехал, а настроение плохое с утра.
В суть въехал. Очень понравилось. Но кода на мой взгляд должно быть раза в 2 меньше. Код==токен.
Мои возражения не по сути, а по дизайну текста. Использовать ключевое слово класс не есть красиво.
Здравствуйте, VladD2, Вы писали: VD>Вот привязка к модели — это, на мой взгляд, не очень правильно.
Как я ни думал, всё равно получалось, что представление без модели это скорее исключение чем правило.
Далее может возникнуть вопрос, а что если для рендеринга нужно несколько моделей. Так это и сейчас, на серверной стороне реализуется через viewmodel.
Грубо говоря должны быть View и View[T]. Оба этих варианта реализуются через шаблоны в моделях.
VD>Это что-то вроде контрола?
Типичный сценарий:
Есть модель User, для неё создаётся контроллер и представления для каждого из действий.
А у нас получается, что все представления User'а являются его методами. Пока я не нашёл отрицательных сторон у этого решения.
VD>Как-то вложенность представления в модель представления выглядит странно. Пока не могу сказать плохо ли это. Но решение неожиданное, как минимум.
Согласен, что выглядит немного необычно. Но, мне кажется, это должно быть очень удобно.
VD>Я тут имею в виду, что в таких контролах может быть произвольный код превращающийся в произвольный жабаскрипт.
Оно так и есть, если хочешь, добавляй метод и вперёд, пиши произвольный код, точно так же как в основной ViewModel.
Здравствуйте, ionoy, Вы писали:
I>Есть модель User, для неё создаётся контроллер и представления для каждого из действий. I>А у нас получается, что все представления User'а являются его методами. Пока я не нашёл отрицательных сторон у этого решения.
Такой дизайн препятствует раздельной компиляции представлений. Не находишь?
VD>>Я тут имею в виду, что в таких контролах может быть произвольный код превращающийся в произвольный жабаскрипт. I>Оно так и есть, если хочешь, добавляй метод и вперёд, пиши произвольный код, точно так же как в основной ViewModel.
ОК. Это здорово!
Остается только вопрос что такое "js" (в коде примеров) и зачем оно надо?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>Такой дизайн препятствует раздельной компиляции представлений. Не находишь?
Насчёт раздельной компиляции надо будет ещё крепко подумать. Я думаю, что всё можно будет сделать и так, но это отдельная и довольно сложная задача.
В ASP.NET, кстати, неслабо приходится извращаться, чтобы раздельно компилировать. Оно только снаружи кажется простым.
VD>Остается только вопрос что такое "js" (в коде примеров) и зачем оно надо?
Мы ведь это уже обсуждали, это вставка произвольного Js кода. Повторно начинать спор не хочу, на данном этапе без Js в любом случае не обойтись.
Возможно, когда-то мы выйдем на такой уровень, где точно не понадобится писать javascript вручную, т.к. абсолютно все случаи будут покрыты фреймворком. Сейчас об этом рано думать.
Здравствуйте, Аноним, Вы писали:
А>В суть въехал. Очень понравилось. Но кода на мой взгляд должно быть раза в 2 меньше. Код==токен. А>Мои возражения не по сути, а по дизайну текста. Использовать ключевое слово класс не есть красиво.
Суть в том, что это код на типизированном языке. "class", "public" и т.п. — это его неотъемлемые элементы.
В принципе можно было бы создать чистый ДСЛ, но средствами Немерла это делать слишком сложно. Вот когда мы доделаем N2, то создавать подобные ДСЛ-и будет намного проще и можно будет немного разгрузить синтаксис. А пока что это встроенные ДСЛ-и.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Сделал прототип Веб фреймворка для Немерле
Здравствуйте, Аноним, Вы писали: А> <ul visible="Tasks().length > 0"> А>Это нормально? что присваивается текст напрямую?
Это пережитки прошлого, я просто не заметил.
А>последний пример больше не работает
Поправили.
Re[14]: Сделал прототип Веб фреймворка для Немерле
От:
Аноним
Дата:
22.08.12 16:03
Оценка:
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, Аноним, Вы писали: А>><a href="#" click="$RemoveTask">Delete</a> А>>тут не понятно какое значение передаеться в RemoveTask
I>Это особенность KnockoutJS, если вызов внутри тела цикла, то передаётся текущий item.
Если 2 вложенных цикла? в немерли может быть цикл с with и вообще куча извращений
Re[15]: Сделал прототип Веб фреймворка для Немерле
Здравствуйте, Аноним, Вы писали:
А>Если 2 вложенных цикла? в немерли может быть цикл с with и вообще куча извращений
Теоретичски можно писать click="() => loopItem.Method(outerLoopItem)", но я это ещё не тестировал.
Все конструкции немерли в разметке повторять не нужно, достаточно основных выражений.
Здравствуйте, ionoy, Вы писали:
А>> <ul visible="Tasks().length > 0"> А>>Это нормально? что присваивается текст напрямую? I>Это пережитки прошлого, я просто не заметил.
А где же контроль типов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Сделал прототип Веб фреймворка для Немерле
От:
Аноним
Дата:
22.08.12 19:16
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>А где же контроль типов?
А он так нужен? контроль типов явно не самое главное в жизни.
Re[14]: Сделал прототип Веб фреймворка для Немерле
VD>>А где же контроль типов? А>А он так нужен? контроль типов явно не самое главное в жизни.
Раньше все представления были сделаны в текстовом виде. Потом постепенно они были переведены на сплайсы.
Я же говорю, не заметил просто. Обновите страницу.
Здравствуйте, Аноним, Вы писали:
VD>>А где же контроль типов? А>А он так нужен? контроль типов явно не самое главное в жизни.
Весь этот фрэймворк разрабатывается в основном для того чтобы иметь контроль типов во время компиляции. Если его нет, то нет и смысла в проекте.
Ну, а все кого контроль типов не интересуют могут смело переходить в форум посвященный скриптам. Здесь им делать не чего. Объяснять в 100501 раз преимущества статической типизации мне что-то в лом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Сделал прототип Веб фреймворка для Немерле
От:
Аноним
Дата:
23.08.12 05:58
Оценка:
Здравствуйте, ionoy, Вы писали:
public this() {
server.Load(tasks => {
Tasks = tasks.ToList();
});
}
public Load() : IEnumerable[Task]
{
[
Task() <- (Title = "Wire the money to Panama", IsDone = true, _destroy = false),
Task() <- (Title = "Get hair dye, beard trimmer, dark glasses and \"passport\"", IsDone = false, _destroy = false),
Task() <- (Title = "Book taxi to airport", IsDone = false, _destroy = false),
Task() <- (Title = "Arrange for someone to look after the cat", IsDone = false, _destroy = false),
]
}
Тут на мой взгляд какая то ересь. В вызове мы передаем параметр, а в реализации параметра нет.
Re: Сделал прототип Веб фреймворка для Немерле
От:
Аноним
Дата:
23.08.12 06:11
Оценка:
Будут ли свойства помечаемые Клиент или Сервер. Такие свойства не должны ходить между клиентом и сервером.
Re[16]: Сделал прототип Веб фреймворка для Немерле
Здравствуйте, Аноним, Вы писали:
А>[code] А>public this() { А>server.Load(tasks => { А>Tasks = tasks.ToList(); А>}); А>}
А>Тут на мой взгляд какая то ересь.В вызове мы передаем параметр, а в реализации параметра нет.
Дело в том, что вызов асинхронный, поэтому приходится добавлять параметр коллбек. Если у вас есть предложения, как это сделать красивее, то пишите.
Здравствуйте, Аноним, Вы писали:
А>Будут ли свойства помечаемые Клиент или Сервер. Такие свойства не должны ходить между клиентом и сервером.
Кстати, стоит учесть, что классы общие для клиента и сервера. Т.е. как бы мы ни помечали поля, они всё равно будут видны на сервере, пускай с невыставленным значением. И если, например, прямиком их куда-то сериализировать, то будут лишние поля. Есть вариант создавать в макросе два класса, но для начала хотелось бы услышать аргументацию в пользу этого решения.
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, Аноним, Вы писали:
А>>Будут ли свойства помечаемые Клиент или Сервер. Такие свойства не должны ходить между клиентом и сервером.
I>Кстати, стоит учесть, что классы общие для клиента и сервера. Т.е. как бы мы ни помечали поля, они всё равно будут видны на сервере, пускай с невыставленным значением. И если, например, прямиком их куда-то сериализировать, то будут лишние поля. Есть вариант создавать в макросе два класса, но для начала хотелось бы услышать аргументацию в пользу этого решения.
public AvailableMeals : List[Meal] { get; set; }
public SeatCount : int;
я могу на клиенте подменить значение и при передаче на сервер.......
Поля могут быть не доступны для изменения с клента. Пароли не должны передаваться на клиент и вообще все неиспользуемые там данные. Так можно усилить безопасность.
Здравствуйте, Аноним, Вы писали:
А> public AvailableMeals : List[Meal] { get; set; } А> public SeatCount : int; А>я могу на клиенте подменить значение и при передаче на сервер....... А>Поля могут быть не доступны для изменения с клента. Пароли не должны передаваться на клиент и вообще все неиспользуемые там данные. Так можно усилить безопасность.
Если я правильно тебя понимаю, то проблема такая:
class User
{
Username : string;
Age : string;
AvatarUrl : string;
Password : string;
}
На клиентской стороне есть представление позволяющее изменять Age и AvatarUrl. Но если злоумышленник добавит в запрос поле Username или Password, то они будут включены в обновление. Так?
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, Аноним, Вы писали:
А>> public AvailableMeals : List[Meal] { get; set; } А>> public SeatCount : int; А>>я могу на клиенте подменить значение и при передаче на сервер....... А>>Поля могут быть не доступны для изменения с клента. Пароли не должны передаваться на клиент и вообще все неиспользуемые там данные. Так можно усилить безопасность.
I>Если я правильно тебя понимаю, то проблема такая:
I>
I>На клиентской стороне есть представление позволяющее изменять Age и AvatarUrl. Но если злоумышленник добавит в запрос поле Username или Password, то они будут включены в обновление. Так?
Как один из вариантов.
В действительности часто бывает что не значительную часть данных надо передать. Кроме того можно ненароком передать ссылку на объект содержащий конфиденциальные данные и они передадутся на клиента.
вообщем есть 4 варианта
сериализируемые
несереализируемые
только клиент
только сервер
детский вопрос: почему в разметках упорно используют XML, а не YAML, который наименее депрессивный?
если править дизайнером, то это несущественно, а руками преимущество последнего очевидно.
Здравствуйте, _Claus_, Вы писали:
_C_>детский вопрос: почему в разметках упорно используют XML, а не YAML, который наименее депрессивный? _C_>если править дизайнером, то это несущественно, а руками преимущество последнего очевидно.
Эм. Дак XML вроде бы ж никто и не использует? В основном у всех банальные текстовые шаблонизаторы (например razor), который на выходе даёт plain-text, который без каких либо конверсий понимается браузером. Или ты не про то?
Здравствуйте, _Claus_, Вы писали:
_C_>детский вопрос: почему в разметках упорно используют XML, а не YAML, который наименее депрессивный? _C_>если править дизайнером, то это несущественно, а руками преимущество последнего очевидно.
XML используется потому, что он больше всего похож на HTML. Теоретически ничто не препятствует написать несколько сменных парсеров. Основную логику для этого переписывать не придётся. На практике нужно, чтобы кто-то этим занялся
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, _Claus_, Вы писали:
_C_>>детский вопрос: почему в разметках упорно используют XML, а не YAML, который наименее депрессивный? _C_>>если править дизайнером, то это несущественно, а руками преимущество последнего очевидно. F> Эм. Дак XML вроде бы ж никто и не использует? В основном у всех банальные текстовые шаблонизаторы (например razor), который на выходе даёт plain-text, который без каких либо конверсий понимается браузером. Или ты не про то?
я посмотрел код примеров этого фреймворка, и понял, что если бы использовался YAML, код был бы и меньше, и компактней, и приятней, в той части где XML.
ИМХО если есть для автора такая возможность, было бы здорово иметь такую опцию.
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, _Claus_, Вы писали:
_C_>>детский вопрос: почему в разметках упорно используют XML, а не YAML, который наименее депрессивный? _C_>>если править дизайнером, то это несущественно, а руками преимущество последнего очевидно.
I>XML используется потому, что он больше всего похож на HTML. Теоретически ничто не препятствует написать несколько сменных парсеров. Основную логику для этого переписывать не придётся. На практике нужно, чтобы кто-то этим занялся
ну а твоему, это доброе дело — YAML вместо XML, или шило на мыло?
Здравствуйте, _Claus_, Вы писали:
_C_>ну а твоему, это доброе дело — YAML вместо XML, или шило на мыло?
Понимаешь, есть много разных удобных движков представления и можно долго спорить какой из них лучший. HTML же получается как общий знаменатель, его знают все. Плюс, в браузере ты в любом случае будешь работать с HTML, а не источником. Поэтому для фреймворков принято по дефолту его поддерживать.
Это однако не означает, что я против других движков, напротив, я только за. Но сейчас эта задача находится где-то в конце списка по важности. Если будет интерес, то посмотри как сделан парсер XML https://github.com/ionoy/NemerleWeb/blob/master/NemerleWeb/HtmlMacro/XmlQuotParser.n
Фактически, всё что нужно это написать аналогичный парсер для другого языка разметки, главное, чтобы он возвращал такие-же данные.
Здравствуйте, _Claus_, Вы писали:
_C_>детский вопрос: почему в разметках упорно используют XML, а не YAML, который наименее депрессивный? _C_>если править дизайнером, то это несущественно, а руками преимущество последнего очевидно.
Будешь делать что-то сделай как тебе нравится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
