Невероятными усилиями удалось транслировать PEG.
Исходный код был немного переделан в связи с некоторыми ограничениями NemerleWeb.
По мере их устранения, код вернется в прежний вид.
Здравствуйте, VladD2, Вы писали:
VD>По поводу: VD>style-..., css-... и т.п.
VD>Откровенно говоря этот ДСЛ не интуитивен. Для его понимания нужно долго и ундно объяснять что это и как работает.
VD>Собственно вопрос: почему нельзя было сделать ДСЛ ближе к оригинальному ХТМЛ? Например, вместо: VD>
VD><div $foreach(c in Children) style-margin-left="$(c.Depth * 6)" ...
VD>
VD>писать нечто вроде: VD>
VD><div $foreach(c in Children) style="margin-left: $(c.Depth * 6)" ...
VD>
Чёрт, пока отдыхал, на форуме целая война прошла. Жаль, что не успел поучаствовать
Тема с атрибутами, едва ли не единственная реальная проблема обсуждённая в соседнем топике. Честно говоря, я думал забить на неё до релиза и починить уже "как нибудь потом", но раз уж столько человек против расширений, то можно и сразу сделать. У меня в этом месяце будет побольше свободного времени, так что думаю сделаем.
Ну и раз уж на то пошло, то кратко отвечу на остальную критику:
Отдельные файлы с шаблонами вынести можно, но по сути это ничего не изменит, скорее только усложнит. Код останется тот же самый, но придётся выдумывать convention для названия шаблона, типа MyModel_Template1.nhtml, который будет вызываться как myModel.Template1.
По поводу того, чтобы отдавать nhtml шаблон на перевёрстку человеку, который совершенно не будет разбираться в фреймворке — это утопия. Сходите на форум к AngularJS и расскажите им, что их подход биндинга плох именно по этой причине Верстальшик не может посмотреть готовую страницу без данных, которые будут к шаблону прибинжены, а для данных проект придётся-таки собирать. Если же HTML оставлять "чистым", и манипулировать им из кода, то это уже не MVVM, и таких проектов у меня была уйма. В итоге получается знатная каша из jQuery, без какой-либо логики для постороннего человека. Зато шаблон кристально чист
MVVM (как, собственно и MVC) предлагает полностью отвязать код от представления. Т.е. представление может обращаться к коду, но не наоборот — код в идеале ничего не знает о конкретном представлении, поэтому в идеале остаётся только дистиллированная бизнес логика.
Опять же, никто не мешает взять готовый макет и практически один-в-один скопировать во View, добавив только атрибуты данных.
Про MainPage.Instance.IsActiveNode(c) я не совсем понял наезда. Да, можно было бы в каждую ноду передавать экземпляр MainPage, чтобы она могла вызывать IsActiveNode. Я выбрал sinlgeton, потому что немного выгоднее по перформансу, так как MainPage не надо передавать в отдельном цикле.
Насчёт отдельной компиляции, то тут тоже всё не так просто. Если у кого есть интерес, то можно будет обсудить.
Здравствуйте, VladD2, Вы писали:
VD>Зайди в этот тест, нажми "Delete" и нажми "Save". Далее внимательно изучи результат. VD>Помнится ionoy там что-то химичил, но результат получился некрасивым. Надо бы поправить.
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, ionoy, Вы писали:
A>2) Какая цель проекта? Какие основные фичи?
Цель у нас амбициозная — создать лучший в мире фреймворк для разработки веб приложений
Основные фичи NN уже перечислил, но я дополню.
Фреймворк предназначен для упрощения написания браузерных приложений, благодаря смешению клиентского и серверного кода. Такой подход позволяет избавится от большей части boilerplate кода. То есть оставить только то, что описывает логику и ни строчки больше. На данный момент мы не так уж и далеко от цели, достаточно посмотреть на исходники меню rsdn.ru
.
Структура приложения состоит из так называемых юнитов. Каждый юнит содержит клиентский код (транслируемый из немерле в яваскрипт), HTML шаблон с биндингами и серверный код. Все эти три части опциональны, т.е. юнит может содержать только логику или только шаблон. По желанию можно оставить и только серверный код, но в этом нет никакого смысла Кстати, из серверного кода на сервере генерируется контроллер, а на клиенте прокси-поле для его использования.
При компиляции макрос разбирает каждый юнит и генерирует из него яваскрипт+html+серверный код, которые в последствии отдаются при запросе. Примеры юнитов можно посмотреть в проекте Samples или в вышеупомянутом меню rsdn.
Одна из интересных возможностей — это использование Немерле макросов. В браузерном коде есть часто используемые паттерны, как, например, тот же throttling. Их как раз очень удобно реализовывать с помощью макросов.
Кроме этих юнитов, для описания логики приложения теоретически не нужно ничего. Это, конечно, не означает, что отпадает необходимость писать серверную бизнес логику — данная проблема лежит вне компетенции нашего фреймворка.
Мы, кстати, на данный момент базируемся поверх ASP.NET MVC. Если у кого-то возникнет необходимость, то можно будет написать адаптер под любой другой серверный фреймворк.
Здравствуйте, ionoy, Вы писали:
I>Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано.
Думаю востребовано.
1. Можно в конец JS файла добавлять такой комментарий:
//@ sourceURL=my-original-name.js
(Возможно надо его оградить переносами строк, был какой-то нюанс не помню уже). Это должно заставить дебаггер отображать этот ресурс именно с этим именем. Chrome и FF это должны поддерживать. Сам я давно этим уже не пользовался, но раньше точно работало.
2. Сейчас вроде как модно Source Maps — механизм посложнее, но и возможностей поболее. Использовать пока не довелось, не разбирался. Chrome DevTools его поддерживает (нужно включить в настройках devtools).
Здравствуйте, Danchik, Вы писали:
D>Надеюсь это случится в этом году )))
Скорее всего.
D>Теперь вопрос, есть ли какой-то механизм задания типизированного интерфейса к жаваскрипту? Например с Cordova. Имееется ввиду что-то подобное:
D>
D>namespace Cordova
D>{
D> [JsIntf]
D> module Camera
D> {
D> public GetPicture(success : Action<string>, error : Action<string>) : void;
D> {
D> // черт его знает что, чтобы при трансляции генерило вызов camera.getPicture(successCallback, errorCallback)
D> }
D> }
D>}
D>
Есть атрибут [JsApi].
Так например добавили родные для яваскрипта регескпы:
[JsApi]
public class RegExp
{
public this(_pattern : string)
{}
public compile() : void
{}
public compile(_pattern : string) : void
{}
public compile(_pattern : string, _modifier : string) : void
{}
public exec(_input : string) : array[string]
{[].ToArray()}
public test(_input : string) : bool
{false}
}
Реализация не нужна, методы будут один в один транслироваться. Коллбеки тоже будут работать.
Здравствуйте, ionoy, Вы писали:
I>Только вот парсер придётся писать с нуля.
Если что, положу тут ссылку на BNF грамматику EcmaScript. http://tomcopeland.blogs.com/EcmaScript.html Правда ничего не знаю насчет ее качества.
На первый взгляд, на пег должна переделаться один в один.
Здравствуйте, Ziaw, Вы писали:
Z>Скорее всего на руби или питоне перепрограммили. Мне, после руби, бесполезная точка с запятой иногда режет глаз. Как и бесполезные круглые скобки, хотя отказ от скобок в руби — довольно дорогое удовольствие.
Ну так это когда было... Тогда ни Питон, ни Руби не имели никакого влияния на развитие других языков. А сейчас эта фишка, видимо, осталась для обратной совместимости. Ну и некоторым нравится осознавать, что, если они знают все правила расстановки точки с запятой, то они экономят до 100 байт с файла
Z>Automatic Semicolon Insertion в руби достаточно дешев, лишь заставляет поменять привычку писать так:
Z>
Здравствуйте, ionoy, Вы писали:
I>Да, мы об этом уже думали. Там вместе с этим надо будет некоторые инфраструктурные изменения сделать, поэтому пока откладывали. I>Сваливать всё в один запрос конечно никуда не годится
Надо это все абстрагировать от самого фреймворка. Сделать удобные способы для вывода на страницу, в файл при компиляции, в script bundler.
Самим городить этот огород с хешами не стоит, ибо оно будет навязывать идеологию и идти вразрез с текущей политикой управления скриптами в проекте. Не стоит сосредотачивать свои усилия на написании своего аналога bundler.
Offtopic:
Я бы посоветовал сейчас сосредоточиться на простом способе подцепить ваш функционал к готовому проекту на любом языке .net (или хотя бы C#) и на раскрутку (seo по "asp.net mvc knockoutjs"). Убежден, что технология выстрелит только при использовании оригинального knockoutjs (либо будучи 100% совместимой с ним). Я понимаю причины которые побудили создать свой велосипед. Но для популярности нужен либо http://knockoutjs.com/ и поддержка MS либо 100% совместимость с ним (и в будущем тоже). Насколько сложно сейчас вернуться на knockoutjs, пусть даже с использованием манкипатчинга?
P.S. у меня на сайте не подсвечивается Source, но подсвечивается Main page source.
Здравствуйте, ionoy, Вы писали:
I>Ещё вопрос. Как мне из макроса узнать, где находится корневая папка проекта во время компиляции? Файлы то нужно куда-то сохранять.
Manager.Option ... если не ошибаюсь. В общем, в опциях командной строки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вам еще вот что нужно сделать:
Сейчас вы генерируете код прямо в страницу. Это плохо. Ибо страница раздувается до безобразия.
ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого.
Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится.
Таким образом, можно будет значительно сократить трафик при небольших изменениях в больших приложениях.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mumusan, Вы писали:
M>Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн).
Если сроки короткие и область вебразработки не очень знакома, я крайне не рекомендую добавлять еще две области с которыми не приходилось сталкивать серьезно (Nemerle и Nemerle.Web). Вам придется разобраться с особенностями языка, особенностями MVVM. То, что напрямую с яваскриптом работать не придется не означает, что без его знания можно обойтись, так что яваскрипт для дебага придется узнать на 5.
Возьмите ASP.NET MVC 4, по нему есть куча туториалов. Для простого сайта можно обойтись без JS, достаточно знания html. Если очень хочется, контроллеры реализуйте на nemerle, язык реально очень приятный.
Ребята делают отличную и довольно уникальную штуку, но использовать ее сейчас можно рекомендовать только тем, кто хорошо понимает, как оно работает, знает плюсы и минусы технологии. Либо тем, кто может себе позволить потратить достаточно времени на поразбираться и доработать напильником. Лично я бы выбрал такую технологию для сайта вроде gmail (сложный UI, большой объем js кода, не требуется индексация поисковиками).
P.S. я тут изрядно нателепатил, так что не судите строго, если чего не угадал по вашему сообщению.
Здравствуйте, VladD2, Вы писали: I>>Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются. VD>Далеко не все. Поменял имя колонки/таблицы — приехали. Разделил таблицу на две — тоже.
Да, без миграций такое не сделать. Но честно говоря мне совершенно не понравилось работать с миграциями. Слишком много телодвижений для, казалось бы, простых изменений.
database MyDB.Version1
table Users
pk id : int;
FirstName : string;
LastName : string;
end
end
database MyDB.Version2
table Users
pk id : int;
FirstName : string;
LastName : string;
FullName : string;
end
end
migration MyDB.Version1 to MyDB.Version2
lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users
$"$(users2.FirstName) $(users2.LastName)" -> users2.FullName;
end
end
Как минимум надо отказаться от id
Кроме того
database MyDB.Version1
table Users
FirstName : string;
LastName : string;
end
end
database MyDB.Version2
table Users
FirstName : string;
LastName : string;
// FullName : string{new {FirstName+LastName}} //если создаеться новый
// FullName : string{get {FirstName+LastName}} //если виртуальное поле
end
end
// в сложном случае
migration MyDB.Version1 to MyDB.Version2
lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users
$"$(users2.FirstName) $(users2.LastName)" -> users2.FullName;
end
end
в простых случаях создавать явный слой миграции не надо. Система должна предусматривать следующие случаи без миграции. Добавление поля и заполнение на основе существующих данных. Выделение части таблицы в подтаблицу.
На ни приходиться 50% изменений.
Здравствуйте, ionoy, Вы писали:
VD>>Первое что хочется заметить — это прочность твоей логики. Какой смысл пытаться обосновывать идеологию своего решения наличием или отсутствием чего-то где-то? Недавно ты так же обосновывал полную ненужность применения реактивной модели тем, что в ASP.NET MVC ее нет, а все ее используют. I>Если я не ошибаюсь, я нигде не говорил, что реактивная модель не нужна. Более того, ещё когда только появился KnockoutJS я делал на нём сайты и был доволен. Скорее всего я говорил о том, что это не основной инструмент веб разработки, так я и сейчас так считаю. Реактивность нужна далеко не всем и далеко не всегда.
Не совсем в тему, но близко:
KnockoutJS изначально было изделием для одноразово показываемых страниц. Он полностью не годился для долгоживущих страниц (типа gmail), т.к. не было возможности остановить их адские биндинги. Мой иссью вроде бы с тех пор разрешили (уже не следил толком) — но я больше в knockout — ни ногой. Это ненужная хрень. Обсервации... Нужен простой и понятный линейный код. На биндинг, на анбиндинг, и на апдейт стэйта при изменении тех или иных элементов форм. Иначе говоря простые старые добрые "винформс" только в другой оболочке. Как бы это не было противно — этот подход работает везде, хоть в вебе — хоть в винформах. Ну и самое главное — наличие вьюмодели — позволяет сгенерить всю эту лапшу без всяких лишних изысков и лишних фреймворков. Ну да — это сложнее, но это точно можно.
AngularJS — вот недавно столкнулись, что создаёт жестоки утечки в памяти бразера (Chrome). В принципе повторяется — но разобраться — почти невозможно. Да и собственно уже новая версия ангулара вышла — а воз и ныне там.
Я лишь кидаю мысь — что вся эта реактивность "там" в JS — имхо, — не нужна. Она нужна в описании модели и всё. Реализовать её — скорее всего дело техники.
Здравствуйте, fddima, Вы писали:
F> KnockoutJS изначально было изделием для одноразово показываемых страниц. Он полностью не годился для долгоживущих страниц (типа gmail), т.к. не было возможности остановить их адские биндинги.
Не совсем понятно, что ты имеешь в виду. Для одноразово показываемых страниц биндинг вообще не нужен, достаточно отрендерить шаблон. А для простых взаимодействий вроще jQuery использовать, чем подлкючать Нокаут.
Он, как и все подобные фреймворки, как раз-таки разрабатывался с направлением на одностраничные приложения.
F> Обсервации... Нужен простой и понятный линейный код. На биндинг, на анбиндинг, и на апдейт стэйта при изменении тех или иных элементов форм.
То есть всё обновлять вручную, типа
В нашем фреймворке нет отдельных примитивов для биндинга, код такой же, как и для любого другого приложения. Привязывается это всё с помощью "магии" по типу AngularJS.
F> Иначе говоря простые старые добрые "винформс" только в другой оболочке. Как бы это не было противно — этот подход работает везде, хоть в вебе — хоть в винформах.
WinForms — это далеко не "простой и понятный линейный код".
F> AngularJS — вот недавно столкнулись, что создаёт жестоки утечки в памяти бразера (Chrome). В принципе повторяется — но разобраться — почти невозможно. Да и собственно уже новая версия ангулара вышла — а воз и ныне там.
Ну это проблема не идеологии, а текущей реализации. Если там действительно есть где-то утечка, то её наверняка поправят. Народ там очень толковый.
F> Я лишь кидаю мысь — что вся эта реактивность "там" в JS — имхо, — не нужна. Она нужна в описании модели и всё. Реализовать её — скорее всего дело техники.
Что значит в описании модели?
Здравствуйте, ionoy, Вы писали:
I>Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано.
Отвечу сразу здесь, чтобы и топикстартеру и Ziaw'у.
M>>Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн).
Если есть дедлайн, то я не советую сейчас закладываться на наш фреймворк. Несмотря на то, что он уже потихоньку взрослеет, проблем там ещё вагон, далеко не всё окончательно решено.
Z> Вам придется разобраться с особенностями языка, особенностями MVVM.
С тонкостями MVVM не придётся разбираться, фреймворк построен так, как будто пишешь обычный шаблон. Данные сами по себе, магическим образом обновляются по мере обновления модели в коде.
Z> То, что напрямую с яваскриптом работать не придется не означает, что без его знания можно обойтись, так что яваскрипт для дебага придется узнать на 5.
Это да. На текущий момент без знания яваскрипта будет тяжело, иначе рискуешь на самую мелкую проблему потратить пол дня — день.
Z>Возьмите ASP.NET MVC 4, по нему есть куча туториалов. Для простого сайта можно обойтись без JS, достаточно знания html. Если очень хочется, контроллеры реализуйте на nemerle, язык реально очень приятный.
Согласен, пока значительно надёжнее будет взять "голый" MVC 4. Если к тому времени, как фреймворк достигнет более менее стабильного состояния проект всё ещё будет идти, то никаких проблем не составит добавлять новые страницы в этом проекте уже на NemerleWeb. Он прекрасно встраивается в готовое приложение.
Z>Ребята делают отличную и довольно уникальную штуку, но использовать ее сейчас можно рекомендовать только тем, кто хорошо понимает, как оно работает, знает плюсы и минусы технологии. Либо тем, кто может себе позволить потратить достаточно времени на поразбираться и доработать напильником.
На данный момент да, т.к. пока ещё много нерешённых проблем. В конечном итоге логика написания страниц получится (имхо) значительно проще, чем та, которая есть в том же ASP.NET MVC.
Z> Лично я бы выбрал такую технологию для сайта вроде gmail (сложный UI, большой объем js кода, не требуется индексация поисковиками).
Для таких задач фреймворк как раз идеально подходит. Но, если честно, немного поделав страницы на фреймворке, я понял, что даже простые вещи удобнее делать с такой архитектурой. Единственное, что нужно решить вопрос с индексацией, т.е. добавить возможность собирать шаблоны на сервере. До этого пока далеко.
Собственно первый более менее стабильный релиз судя по всему получится выпустить до нового года. Надеюсь к этому времени получится написать хотя бы базовую документацию, а то я и сам сейчас иногда не могу вспомнить как некоторые вещи у нас делаются
Здравствуйте, _NN_, Вы писали:
_NN>Проблема известная. _NN>Будем решать.
Я правильно понимаю, что проблема в том, чтобы натравить преттифаер после того, как код будет выведен на страницу? В оригинальном нокауте я бы такую проблему решил с помощью кастом биндинга. Их планируете? Без них, имхо, использовать в чем-то серьезном будет сложно. Ибо проблемы, подобные этой без них решаются только нетривиальными решениями совмещенными с правкой самого фреймворка.
Кстати, а вы не думали над использованием typescript как типизатора для внешнего js? Там довольно несложный синтаксис, распарсить несложно, вот скрестить его с немерловым будет сложнее, тут я пока ничего путнего не придумал.
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, ionoy, Вы писали:
A>В коде есть упоминание throttle. Не смог найти в интернете. Можно ссылку что это такое и с чем его едят?
Вкратце это нужно, чтобы не реагировать на событие сразу, а по истечении некоторого времени.
В случае поиска мы не хотим вызывать поиск на каждый символ, это будет очень накладно, а только когда пользователь закончил ввод.
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, ionoy, Вы писали:
A>В коде есть упоминание throttle. Не смог найти в интернете. Можно ссылку что это такое и с чем его едят?
Этот паттерн обычно используют, когда нужна строка поиска. Если отсылать поисковый запрос на каждое нажатие клавиши, то получится что мы отправим как минимум столько запросов, сколько букв в слове. Такой подход может вызвать проблемы с производительностью, да и никому не нужен. Для того, чтобы избежать этой проблемы перед запросом вставляется таймаут, и если до истечения этого таймаута была нажата следующая кнопка, то таймаут сбрасывается. Таким образом запрос отсылается только на то нажатие, которое было "последним".
На самом деле название throttle не совсем корректное, более правильно называть его debounce. Но, throttle как-то более распространён, имхо.
Здравствуйте, WolfHound, Вы писали:
WH>Lists and collections глючит. Попробуй добавить/удалить несколько раз.
Интересная проблема, странно, что о ней нет ничего на сайте KnockoutJs.
Дело в том, что Seats.Remove конвертируется в вызов метода destroy (observableArray), который в свою очередь выставляет у объекта свойство _destroy = true.
Объекты, у которых _destroy == true, игнорируются при биндингах, как будто их нет. Но, загвоздка в том, что свойство length, после destroy() не изменяется. А специального метода length(), который бы учитывал _destroy у observableArray тоже нет.
Очень странная недоработка. Видимо придётся пока вообще отказаться от destroy в пользу remove.
Добавил сэмпл Computation Expressions.
В данном примере используется comp list, но если автор Nemerle.ComputationExpressions согласится помочь, то можно будет прикрутить и comp async.
Здравствуйте, ionoy, Вы писали:
I>Добавил сэмпл Computation Expressions.
Интересно.
Я тут маленько посмотрел на код.
ИМХО Write и Transform ты зря засунул в JsAST просто по тому, что они захламляют АСТ и из-за ниx трудно понять, что АСТ из себя представляет. Лучше их вынести в отдельные методы. Тем более что match проверяет полностью ли ты все сматчил.
Для такого something :: If(c, t, e) :: []
Есть такой синтаксис [something, If(c, t, e)]
Кстати то, что эти два паттерна обрабатываются одинаково точно не ошибка? Ибо в первом паттерне аргументы меняются местами.
I>В данном примере используется comp list, но если автор Nemerle.ComputationExpressions согласится помочь, то можно будет прикрутить и comp async.
А что именно нужно? Там основная сложность в рантайме. Его нужно переписать под js?
Могу помогать идейно и морально. Писать не вариант. Я на Н2 загружен по самые не могу.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ionoy, Вы писали:
I>В данном примере используется comp list, но если автор Nemerle.ComputationExpressions согласится помочь, то можно будет прикрутить и comp async.
Для асинка теперь есть отдельная реализация. Вроде как более удобная.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>ИМХО Write и Transform ты зря засунул в JsAST просто по тому, что они захламляют АСТ и из-за ниx трудно понять, что АСТ из себя представляет. Лучше их вынести в отдельные методы. Тем более что match проверяет полностью ли ты все сматчил.
Первые несколько недель разработки, у меня как раз было несколько методов: Write, Transform и Recurse (который, наверное, надо переименовать в Traverse). Показалось неудобным то, что на каждое изменение AST мне приходилось повторять его ещё в трёх местах. А так как на тот момент я часто менял AST, то в конце концов не выдержал и зарефакторил в текущее состояние. То, что есть сейчас, конечно, не так удобно читается, зато легко поддерживается (как бы это ни странно звучало).
WH>Для такого something :: If(c, t, e) :: [] WH>Есть такой синтаксис [something, If(c, t, e)]
Ага, мне NN уже намекнул. Не знаю, с чего я решил, что матчить можно только cons'ом.
WH>Кстати то, что эти два паттерна обрабатываются одинаково точно не ошибка? Ибо в первом паттерне аргументы меняются местами.
Ошибка. Вспешке не подумал о том, что порядок выполнения решает.
I>>В данном примере используется comp list, но если автор Nemerle.ComputationExpressions согласится помочь, то можно будет прикрутить и comp async. WH>А что именно нужно? Там основная сложность в рантайме. Его нужно переписать под js?
Нужно совсем немного, ключевое слово compdef которое с правой стороны принимало бы вызов метода, у которого последний параметр TResult -> void и засовывало "продолжение" в этот параметр. Как это сделать, я, если честно, не разобрался.
было бы позитивно написать краткую инструкцию для начала использования:
как то ставим то и то, создаем каталог х, копируем туда пример из y, запускаем на компиляцию или еще что и пр.
есть мнение, что не все знают ASP net и прочую лабуду, и как ее активировать в связке с NemerleWeb.
это помогло бы не только тем, что вообще не в теме web и asp но и тем, кто имеет дело с альтернативными технологиями.
Re[2]: Общая информация по NemerleWeb для чайников
Здравствуйте, _Claus_, Вы писали:
_C_>было бы позитивно написать краткую инструкцию для начала использования: _C_>как то ставим то и то, создаем каталог х, копируем туда пример из y, запускаем на компиляцию или еще что и пр. _C_>есть мнение, что не все знают ASP net и прочую лабуду, и как ее активировать в связке с NemerleWeb. _C_>это помогло бы не только тем, что вообще не в теме web и asp но и тем, кто имеет дело с альтернативными технологиями.
Это всё будет как только мы будем уверены, что фреймворк готов для обычного пользователя. На данный момент там ещё слишком много недоработок и досадных багов.
Если интересно просто "поиграться", то делай клон с гитхаба и работай в проекте MVCTest. Никакой особенной магии там не нужно.
Хотелось бы услышать от сообщества предложения по поводу работы с БД. Моё главное пожелание, это возможность в простых случаях не писать ни строчки "мета" кода. То есть весь код работы с базой это db.Add и подобное, а генерацией базы и прочим должен заниматься фреймворк. И отталкиваясь от этого пошаговая расширяемость.
Здравствуйте, ionoy, Вы писали:
I>Хотелось бы услышать от сообщества предложения по поводу работы с БД. Моё главное пожелание, это возможность в простых случаях не писать ни строчки "мета" кода. То есть весь код работы с базой это db.Add и подобное, а генерацией базы и прочим должен заниматься фреймворк. И отталкиваясь от этого пошаговая расширяемость.
Генерировать сторепроц?
Здравствуйте, ionoy, Вы писали:
I>Варианты пока не работают. Надо прикинуть, какой ЖС для них генерировать и вообще какая функциональность обычных классов перейдёт и к ним.
Надо.
I>Паттерн матчинг должен работать в полную силу, кроме, конечно, сопоставления вариантов.
Ну, дык варианты в ПМ самое вкусное. Надо сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Хотелось бы услышать от сообщества предложения по поводу работы с БД. Моё главное пожелание, это возможность в простых случаях не писать ни строчки "мета" кода. То есть весь код работы с базой это db.Add и подобное, а генерацией базы и прочим должен заниматься фреймворк. И отталкиваясь от этого пошаговая расширяемость.
А чем использование линка не устраивает?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Хотелось бы услышать от сообщества предложения по поводу работы с БД. Моё главное пожелание, это возможность в простых случаях не писать ни строчки "мета" кода. То есть весь код работы с базой это db.Add и подобное, а генерацией базы и прочим должен заниматься фреймворк. И отталкиваясь от этого пошаговая расширяемость.
db.Users.Insert(() => new User { Name = "Новый юзер" });
Это C# + BLToolkit
Здравствуйте, Jack128, Вы писали:
J>db.Users.Insert(() => new User { Name = "Новый юзер" }); J>Это C# + BLToolkit
Да, про BLT знаю и, кстати, предполагал именно его использовать для доступа. Вопрос тут скорее для того, что может быть кто-то придумает нечто полезное и интересное с использованием макросов.
Здравствуйте, ionoy, Вы писали:
I>Вполне устраивает. Меня больше интересуют инфраструктурные вопросы, как генерировать базу и прочее. I>Может у кого-то возникнет интересная идея.
У Ziaw есть движок миграций. Можно для начала его приспособить. Но лично я бы предпочел подход от модели (что МС называют код-фирст), когда описывается модель в виде некоторого ДСЛ-я и уже по ней генерируется БД и миграции.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, VladD2, Вы писали:
VD>>А чем использование линка не устраивает?
I>Вполне устраивает. Меня больше интересуют инфраструктурные вопросы, как генерировать базу и прочее. I>Может у кого-то возникнет интересная идея.
Позволю процитировать один свой мысль по этому поводу
Объектная модель мне по многим причинам кажется лучше, при том, что если кто-то считает лучшей реляционную,
это должно быть поддержано и продумано. Очень желательно иметь технику связи с базами данных, независимую от
используемой СУБД и прозрачную для кода использования. Это должно выглядеть так, что вроде никакой базы нет,
т. е. код не нуждается в переделках не только при переходе от одной СУБД к другой, и при переходе к использованию базы.
То, что это возможно и как примерно выглядит, можно посмотреть в Zdb, приближение которой к полному Zen упирается в текущие ограничения N.
выглядеть это должно так:
//using zdb
//using no_dbusing mongo_db
[Ndb] //все, что требуется,- добавить в рутовый класс для работы с Ndb-схемамиclass x
d : NDict[int, string]
l : NList[x]
class u: x
k: int
lk : NList[int]
class i : x
j : NHash[myclass]
Nlist, NDict, NHash ... — макротипы стандартной Nid библиотеки, которые в зависимости от активированной схемы разворачиваются
либо в стандартные.Net/Java коллекции, либо специализированные для mongo или любой другой СУБД, для которой написан Ndb метаконнектор.
Код связи и обслуживания генерируется при компиляции (см Zdb), а работа с данными одинакова и прозрачна для всех поддерживаемых Ndb.
Уверен, что это strongly must have killer-фича, наглядно показывающая любому скептику, что мы не просто так тут собрались.
и здесь реализация реализация этого для случая встроенной бд.
ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, _Claus_, Вы писали:
_C_>>ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора
_NN>Поднял тему — развивай
для тех, кому лень читать что попало — основная мысль:
макротипы — это штука, которая стирает (прячет) грань между простым кодом и макросом.
работая с макротипом(и), как с обычным классом, мы в итоге получаем любой согласованный везде код, количество и сложность которого ограничена только нашей фантазией.
имея макротипы для бд или гуя мы перекомпилировав с одним другим юсингом получим высокооптимальный код для заказанной платформы.
со всеми связками, хмлями и прочей лабудой, нужной для платформозависимого кода, и о которой разумному программисту и знать не надо.
Здравствуйте, _Claus_, Вы писали:
_C_>> уже это показывал здесь — реакции не было. вообще. подожду думаю лет пять. обычно потом принимают как родное.
Так мало поддержки, нужно еще и реализовывать.
_C_>макротипы — это штука, которая стирает (прячет) грань между простым кодом и макросом. _C_>работая с макротипом(и), как с обычным классом, мы в итоге получаем любой согласованный везде код, количество и сложность которого ограничена только нашей фантазией. _C_>имея макротипы для бд или гуя мы перекомпилировав с одним другим юсингом получим высокооптимальный код для заказанной платформы. _C_>со всеми связками, хмлями и прочей лабудой, нужной для платформозависимого кода, и о которой разумному программисту и знать не надо.
Теперь ясно.
Я бы добавил в желания еще поддержку макрометодов.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, _Claus_, Вы писали:
_C_>>> уже это показывал здесь — реакции не было. вообще. подожду думаю лет пять. обычно потом принимают как родное. _NN>Так мало поддержки, нужно еще и реализовывать.
попробую. после парсера.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, _NN_, Вы писали:
А>Можно пример макротипа? (с кодом) И макрометода....
using ProtoScheme
//наследование от типа есть считывание шаблона
//и создание заглушек по умолчанию, в точности возвращающих то, что описано
macrotype NxList[T] : List[T] {}
//public Contains(x: T): bool такое создается автоматом
// <[Contains(x)]>public SubListBy(range: T): NxList[T] //новый макрометод макротипа
<[
def range = IndexOf(range); //List.IndexOf
NxList(this.Range(0, range));
]>
using NoScheme
//нас все устраивает по имеющемуся умолчанию
macrotype NxList[T] : ProtoScheme.NxList[T] {}
//другой файлusing DBScheme
macrotype NxList[T] : ProtoScheme.NxList[T]
//переопределяемpublic this()
<[ DbBigList[T]() ]>
//переопределяемpublic SubListBy(range: T): NxList[T]
//что то считаем
<[и тут]>
//переопределяемpublic Contains(x: T): bool
<[ def data4qyery = нудный_код();
...
this.QueryContains(что_насчитали_выше)
]>
... для остальных методов, определенный у NxList(List)
имеет две модели генерации — NoScheme, DBScheme
они включают в себя идентичные группы объектов, которые для пользователя ведут себя одинаково.
в процессе компиляции юсинг модели в корне меняет код, который получается в итоге.
в данном случае при NoScheme использование NxList порождает код стандартный контейнеров, при DBScheme — работу с удаленной базой.
без изменений кода. в процессе генерации может порождаться xml, javascript, бог знает что еще. прозрачно и незаметно.
Здравствуйте, ionoy, Вы писали:
I>Да, про BLT знаю и, кстати, предполагал именно его использовать для доступа.
C blt, кстати, та же проблема, что и с nemerle.dll, зависимость от конкретной версии. Если Nemerle.Web еще можно включить в инсталятор nemerle и она всегда будет ссылаться на доступную версию nemerle.dll, то ее зависимость от конкретного тулкита будет уже довольно печальным фактом.
Здравствуйте, VladD2, Вы писали: VD>У Ziaw есть движок миграций. Можно для начала его приспособить. Но лично я бы предпочел подход от модели (что МС называют код-фирст), когда описывается модель в виде некоторого ДСЛ-я и уже по ней генерируется БД и миграции.
Главное, что мне нравилось в nHibernate, это как раз-таки автоматическая генерация и обновление базы по модели. Наверное, что-то вроде этого и надо будет прикрутить, например взять из EF. Если кто знает где ещё это реализовано, предлагайте.
Здравствуйте, Ziaw, Вы писали: Z>C blt, кстати, та же проблема, что и с nemerle.dll, зависимость от конкретной версии. Если Nemerle.Web еще можно включить в инсталятор nemerle и она всегда будет ссылаться на доступную версию nemerle.dll, то ее зависимость от конкретного тулкита будет уже довольно печальным фактом.
Есть какие-то идеи как это решить?
Здравствуйте, VladD2, Вы писали: VD>Уж на Немерле можно было бы и более приличный синтаксис сделать. Insert/Update/Delete в стиле SQL были бы очень приятной фичей.
Это наверное вопрос предпочтений, но я тот же линк с SQL синтаксисом использую только в особо запутаных случаях.
А подобную фичу кто-нибудь мог бы реализовать отдельным макросом, не зависящим от фреймворка или чего-то ещё.
Просто должны быть подстановки по договорённости select -> Select(), и возможность их оверрайдить через макросы уровня сборки.
Здравствуйте, ionoy, Вы писали:
I>Главное, что мне нравилось в nHibernate, это как раз-таки автоматическая генерация и обновление базы по модели. Наверное, что-то вроде этого и надо будет прикрутить, например взять из EF. Если кто знает где ещё это реализовано, предлагайте.
EF сюда тащить — это перебор.
Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД.
Вообщем — это большая отдельная задача и я бы посоветовал не смешивать их.
Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД.
А еще лучше скооперироваться с IT'ом. И сделать крутой BLT для немерла.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД.
Почему тяжело? Обновлять базу данных "вперёд" как раз легко. Насчёт отката не уверен, никогда не приходилось.
Здравствуйте, ionoy, Вы писали:
VD>>Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД. I>Почему тяжело? Обновлять базу данных "вперёд" как раз легко. Насчёт отката не уверен, никогда не приходилось.
На словах — легко. А когда погрузишься в проблему, то поймешь, что все очень сложно.
Там основная проблема — сохранность данных и возможность безболезненно переключаться между новыми и старыми версиями. В решении из РоР (аналог которому сделал Зива) проблема решается ручным написанием миграционных скриптов. В них описывается как будут меняться данные.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Там основная проблема — сохранность данных и возможность безболезненно переключаться между новыми и старыми версиями. В решении из РоР (аналог которому сделал Зива) проблема решается ручным написанием миграционных скриптов. В них описывается как будут меняться данные.
Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются. С откатом назад будет больше проблем, но ненамного. Естественно удалятся данные, для которых больше нет таблиц/полей.
Здравствуйте, ionoy, Вы писали:
I>Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются. С откатом назад будет больше проблем, но ненамного. Естественно удалятся данные, для которых больше нет таблиц/полей.
Будет круто если они не будут удаляться. И тогда можно будет менять версии БД не теряя данные.
Для этого нужно создать довольно хитрый ДСЛ.
Он будт состоять из двух частей.
1)Описание данных.
2)Описание миграций.
Описание миграций нужно делать на основе линз. Это однозначные двусторонние отображения.
Например, если мы добавляем колонку, то получаем примерно такой код.
database MyDB.Version1
table Users
pk id : int;
FirstName : string;
LastName : string;
end
end
database MyDB.Version2
table Users
pk id : int;
FirstName : string;
LastName : string;
FullName : string;
end
end
migration MyDB.Version1 to MyDB.Version2
lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users
$"$(users2.FirstName) $(users2.LastName)" -> users2.FullName;
end
end
Теперь при преобразовании из версии 1 в версию 2 у нас поле FullName будет заполнено на основе FirstName и LastName.
При обратном преобразовании будет создана таблица, в которую будут сложены значения поля FullName.
Если при этом при работе с версией 1 мы добавим пользователей, то при миграции на версию 2 мы восстановим сохраненные данные для тех пользователей что успели побывать в версии 2. И сгенерируем только для тех, что были добавлены в версии 1.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, ionoy, Вы писали:
I>>Ну я же говорю, вперёд легко мигрировать, данные всё сохраняются. С откатом назад будет больше проблем, но ненамного. Естественно удалятся данные, для которых больше нет таблиц/полей. WH>Будет круто если они не будут удаляться. И тогда можно будет менять версии БД не теряя данные.
Сейчас почитал, они не удаляются. Поддерживаются только новые таблицы/колонки, именно для того, чтобы не терять данные. Тем более, что одной базой данных может пользоваться несколько систем с разными требованиями.
WH>Для этого нужно создать довольно хитрый ДСЛ. WH>Он будт состоять из двух частей. WH>1)Описание данных. WH>2)Описание миграций.
Вот что мне не нравится, это как раз необходимость на каждый чих писать кучу кода. Может если получится дистиллировать изменения в короткие "фразы", то будет легче.
WH>migration MyDB.Version1 to MyDB.Version2 WH> lense users1 : MyDB.Version1.Users <-> users2 : MyDB.Version2.Users WH> $"$(users2.FirstName) $(users2.LastName)" -> users2.FullName; WH> end WH>end WH>[/nemerle] WH>Теперь при преобразовании из версии 1 в версию 2 у нас поле FullName будет заполнено на основе FirstName и LastName.
Если бы миграции состояли только из таких выражений, то может быть было бы легче.
Здравствуйте, WolfHound, Вы писали:
VD>>Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД. WH>А еще лучше скооперироваться с IT'ом. И сделать крутой BLT для немерла.
BLT и так есть. Тут речь о несколько другом. Речь о чем-то вроде миграций для РоР. Фиче позволяющей создавать и развивать БД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
VD>>Далеко не все. Поменял имя колонки/таблицы — приехали. Разделил таблицу на две — тоже.
I>Да, без миграций такое не сделать.
Сделать можно. Но нужно не мало потрудиться/поломать голову.
I>Но честно говоря мне совершенно не понравилось работать с миграциями. Слишком много телодвижений для, казалось бы, простых изменений.
+1
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Общая информация по NemerleWeb
От:
Аноним
Дата:
31.08.12 17:53
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>Былобы прикольно обновление без отключения пользователей
VD>+1 Будет над чем по ржать.
Здравствуйте, VladD2, Вы писали:
VD>Компилять все с исходников!
Это мысль. Надо выяснить, умеет ли nuget делать пакеты из проектов с исходным кодом. Потому, что подключать проект с исходниками руками удовольствие ниже среднего.
Здравствуйте, Ziaw, Вы писали: Z>Это мысль. Надо выяснить, умеет ли nuget делать пакеты из проектов с исходным кодом. Потому, что подключать проект с исходниками руками удовольствие ниже среднего.
А Nemerle.dll и Nemerle.Compiler.dll тоже компилять? Не будет конфликтов?
Во первых участить сборки компилятора Nemerle.
Вместо стабильной версии раз в год как сейчас, каждый месяц-два выпускать бета версии, а стабильные раз в 3 месяца например.
Далее все опциональные пакеты которые идут в установщике вынести в NuGet.
Установщик должен содержать только минимальный набор компилятор (поддержка C# и другие необходимые вещи) + интеграция.
Остальное пусть идет из NuGet, заодно это добавит версионность для библиотек.
Здравствуйте, _NN_, Вы писали:
_NN>Во первых участить сборки компилятора Nemerle. _NN>Вместо стабильной версии раз в год как сейчас, каждый месяц-два выпускать бета версии, а стабильные раз в 3 месяца например.
Они и так частые. Ночные.
_NN>Далее все опциональные пакеты которые идут в установщике вынести в NuGet. _NN>Установщик должен содержать только минимальный набор компилятор (поддержка C# и другие необходимые вещи) + интеграция. _NN>Остальное пусть идет из NuGet, заодно это добавит версионность для библиотек.
И для какой версии предлагаешь собирать Nemerle.Web?
_NN>Кроме того увеличит присутствие Nemerle в NuGet
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, _NN_, Вы писали:
_NN>>Во первых участить сборки компилятора Nemerle. _NN>>Вместо стабильной версии раз в год как сейчас, каждый месяц-два выпускать бета версии, а стабильные раз в 3 месяца например.
Z>Они и так частые. Ночные.
Я про стабильные, их нужно чаще выкладывать.
_NN>>Далее все опциональные пакеты которые идут в установщике вынести в NuGet. _NN>>Установщик должен содержать только минимальный набор компилятор (поддержка C# и другие необходимые вещи) + интеграция. _NN>>Остальное пусть идет из NuGet, заодно это добавит версионность для библиотек.
Z>И для какой версии предлагаешь собирать Nemerle.Web?
Для последней стабильной.
Можно для 2-х последних стабильных версий например, хотя в этом я не вижу смысла.
Если бы фреймворк обновлялся часто, была бы точно такая же проблема.
Хотя вот, даже сегодня если выпускаешь библиотеку тебе нужно собирать 3 а то и больше версий под разные версии фреймворков.
Здравствуйте, _NN_, Вы писали:
Z>>И для какой версии предлагаешь собирать Nemerle.Web? _NN>Для последней стабильной. _NN>Можно для 2-х последних стабильных версий например, хотя в этом я не вижу смысла.
То есть каждый автор должен апдейтить пакет каждые месяц-два?
Здравствуйте, Ziaw, Вы писали:
Z>То есть каждый автор должен апдейтить пакет каждые месяц-два?
Мне не нравится , что стабильная версия выходит раз в год.
У нас тут не целый фреймворк ведь.
Есть идеи как это решить ?
Если найти как не прибивать номер версии гвоздями, то можно придумать например так: мажорная версия обновляется при изменении публичного контракта, а минорная при внутренних изменениях.
И при обновлении мажорной версии выбора нет, нужно собирать, а иначе кто знает что поломается.
А в другом случае просто изменить требуемую версию.
Это вообще можно как-то сделать ?
В любом случае если будут зависимости между разными библиотеками, то тут конечно будет еще запутанней.
Здравствуйте, ionoy, Вы писали:
I>Да, без миграций такое не сделать. Но честно говоря мне совершенно не понравилось работать с миграциями. Слишком много телодвижений для, казалось бы, простых изменений.
Это дело привычки. Я миграции пишу быстрее чем делаю таблицы через графический интерфейс. Это простые случаи. Когда же надо мигрировать данные, лучше миграций вообще ничего нет, надо написать только нужный код, ни одной лишней строчки. Проблема отката назад есть, но откат назад нужен далеко не всегда, обычно достаточно восстановить бэкап и накатить все что нужно снова.
Здравствуйте, ionoy, Вы писали:
Z>>Это мысль. Надо выяснить, умеет ли nuget делать пакеты из проектов с исходным кодом. Потому, что подключать проект с исходниками руками удовольствие ниже среднего.
I>А Nemerle.dll и Nemerle.Compiler.dll тоже компилять? Не будет конфликтов?
Нет конечно. Я предлагаю научиться добавлять библиотеки к своему проекту прямо в исходниках. Не уверен, что немерловые имеет смысл так добавлять.
Здравствуйте, WolfHound, Вы писали:
WH>Будет круто если они не будут удаляться. И тогда можно будет менять версии БД не теряя данные.
WH>Для этого нужно создать довольно хитрый ДСЛ. WH>Он будт состоять из двух частей. WH>1)Описание данных.
Вся схема в одном файле или можно в нескольких? Версию next предлагается создавать копипастой?
WH>2)Описание миграций.
Не все линзы обратимы.
update tbl1 set state=1 where state in (3, 4)
Да и с автоматическим бэкапом данных тоже не все гладко, оно будет очень дорогой операцией на продакшен базах, а время деплоя хочется минимизировать.
Re[12]: Общая информация по NemerleWeb
От:
Аноним
Дата:
04.09.12 12:42
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, WolfHound, Вы писали:
WH>>Будет круто если они не будут удаляться. И тогда можно будет менять версии БД не теряя данные.
И хранить кучу не нужных данных? Которые все равно надо обновлять ради возможности откатить? Не нужно. WH>>Для этого нужно создать довольно хитрый ДСЛ. WH>>Он будт состоять из двух частей. WH>>1)Описание данных.
Z>Вся схема в одном файле или можно в нескольких? Версию next предлагается создавать копипастой?
Верный вопрос. WH>>2)Описание миграций.
Z>Не все линзы обратимы.
А бывает еще что релизы ветвятся...
Z>Да и с автоматическим бэкапом данных тоже не все гладко, оно будет очень дорогой операцией на продакшен базах, а время деплоя хочется минимизировать.
Бакап делать по любому причем полный.
Здравствуйте, Ziaw, Вы писали:
Z>Нет конечно. Я предлагаю научиться добавлять библиотеки к своему проекту прямо в исходниках. Не уверен, что немерловые имеет смысл так добавлять.
Они рыжие что ли?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Z>>Нет конечно. Я предлагаю научиться добавлять библиотеки к своему проекту прямо в исходниках. Не уверен, что немерловые имеет смысл так добавлять.
VD>Они рыжие что ли?
стандартные библиотеки? какую проблему пытаемся решить подключая их в исходниках?
Здравствуйте, Аноним, Вы писали:
А>И хранить кучу не нужных данных? Которые все равно надо обновлять ради возможности откатить? Не нужно.
+1
Z>>Не все линзы обратимы. А>А бывает еще что релизы ветвятся...
Не очень понял мысль. Ветвятся и что? На конкретной базе все равно конкретная ветка запускается.
Z>>Да и с автоматическим бэкапом данных тоже не все гладко, оно будет очень дорогой операцией на продакшен базах, а время деплоя хочется минимизировать. А>Бакап делать по любому причем полный.
Горячий бэкап делается до деплоя, просто журналы скидываются, это очень быстро. А вот сохранять данные, для обратных миграций мне бы не хотелось.
Re[14]: Общая информация по NemerleWeb
От:
Аноним
Дата:
04.09.12 18:16
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Аноним, Вы писали:
А>>И хранить кучу не нужных данных? Которые все равно надо обновлять ради возможности откатить? Не нужно.
Z>+1
Z>>>Не все линзы обратимы. А>>А бывает еще что релизы ветвятся...
Z>Не очень понял мысль. Ветвятся и что? На конкретной базе все равно конкретная ветка запускается.
Есть несколько клиентов с небольшой разницей в функционале. Обновления накатываются одни и те же. Но вот Откат может быть существенно разный. Z>>>Да и с автоматическим бэкапом данных тоже не все гладко, оно будет очень дорогой операцией на продакшен базах, а время деплоя хочется минимизировать. А>>Бакап делать по любому причем полный.
Z>Горячий бэкап делается до деплоя, просто журналы скидываются, это очень быстро. А вот сохранять данные, для обратных миграций мне бы не хотелось.
Изменения могут не встать из за ошибок. На продакшине может вылезти ошибка и что бы максимально быстро решить ситуацию может потребываться откатить все назад. По умолчанию при миграции обязан запускаться бакап. И обратная миграция тут не причем.
Здравствуйте, Аноним, Вы писали:
А>Изменения могут не встать из за ошибок. На продакшине может вылезти ошибка и что бы максимально быстро решить ситуацию может потребываться откатить все назад. По умолчанию при миграции обязан запускаться бакап. И обратная миграция тут не причем.
Обязан, но это не задача фреймворка. Ибо процедура бэкапа очень специфична для каждой конкретной серьезной бд. Как только база перестает быть very small в трактовке оракла — для настройки процедуры бэкапа приходится привлекать специально обученного DBA. Я не представляю как это дело можно абстрагировать в миграциях. Разве что запустить нужный батник по хуку. Горячий бэкап базы может стать очень быстрой процедурой, но его технология зависит от настроек конкретного сервера. Универсальный же способ однозначно не подойдет ни для одной продакшен БД.
Здравствуйте, VladD2, Вы писали:
Z>>стандартные библиотеки? какую проблему пытаемся решить подключая их в исходниках?
VD>Зависимости от них.
Мы ее только усугубим. Две библиотеки собранные таким образом в составе разных солюшенов не смогут работать вместе.
Re[16]: Общая информация по NemerleWeb
От:
Аноним
Дата:
05.09.12 04:43
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Аноним, Вы писали:
А>>Изменения могут не встать из за ошибок. На продакшине может вылезти ошибка и что бы максимально быстро решить ситуацию может потребываться откатить все назад. По умолчанию при миграции обязан запускаться бакап. И обратная миграция тут не причем.
Z>Обязан, но это не задача фреймворка. Ибо процедура бэкапа очень специфична для каждой конкретной серьезной бд. Как только база перестает быть very small в трактовке оракла — для настройки процедуры бэкапа приходится привлекать специально обученного DBA. Я не представляю как это дело можно абстрагировать в миграциях. Разве что запустить нужный батник по хуку. Горячий бэкап базы может стать очень быстрой процедурой, но его технология зависит от настроек конкретного сервера. Универсальный же способ однозначно не подойдет ни для одной продакшен БД.
1с микрософт 300г стандартными способами. С ораклом дела особо не имел.
Здравствуйте, Аноним, Вы писали:
А>1с микрософт 300г стандартными способами. С ораклом дела особо не имел.
Я говорю про стандартные способы. Их надо конфигурить, чтобы все было так как нужно. Иначе замучаешься ждать пока бэкап сделается, да и с местом проблемы начнутся.
Здравствуйте, ionoy, Вы писали:
I>Там сейчас баг в IE и некоторых других браузерах, попозже исправим. I>Попробуй Chrome, FF или IE10, там должно работать.
FF 15 цвет выбрать можно. Квадратик всегда белый.
IE 9 цвет выбрать нельзя (в комбобоксе пусто). Квадратик красный.
Других браузеров нет и ставить лень.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Так как KnockoutJS привносил много ограничений в генерируемый код, было решено сменить его на что-то более прогрессивное. Первоначально выбор пал на AngularJS, но в последствие оказалось, что он тоже сильно opinionated, поэтому пришлось бы генерировать код, заточенный конкретно под него. Ну и к тому же нам от него нужен только биндинг, и ради этого тащить всю либу как-то неправильно.
Зато в процессе его изучения я нашёл, что биндинг там реализован очень просто. Тупо проходимся по всем элементам, к которым прибинжены значения, создаём для них листенеры, и потом просто на каждый чих проверяем изменилось ли значение, и если да, то обновляем элемент. Там есть две основных функции $apply и $digest.
Псевдокод:
function $apply(valueUpdater) {
valueUpdater();
$digest();
}
function $digest() {
var changeFound = false;
do {
for(var listener in allListeners)
changeFound = listener.CheckIfValueChanged();
} while(changeFound);
}
Так как большинство изменений происходит внутри самих биндингов, то их запросто можно обернуть в $apply. Если значение изменяется извне (таких сценариев очень, очень мало), то $digest надо вызывать вручную.
Вот я и прикинул, что проще написать подобную либу самому, заодно избавится от любых ограничений, которые накладывались сторонними либами. Так что теперь NemerleWeb работает на нашей либе nweb.js, её можно найти в NemerleWeb.Samples/Scripts/nweb.js. Потом она переедет в более удобное место.
Здравствуйте, ionoy, Вы писали:
I>Вот я и прикинул, что проще написать подобную либу самому, заодно избавится от любых ограничений, которые накладывались сторонними либами. Так что теперь NemerleWeb работает на нашей либе nweb.js, её можно найти в NemerleWeb.Samples/Scripts/nweb.js. Потом она переедет в более удобное место.
Здравствуйте, ionoy, Вы писали:
I>На http://user1663.netfx45lab.discountasp.net/ появился пример Chat using SignalR, где можно посмотреть на это вживую, а так же увидеть код.
Похоже он не работает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Зато в процессе его изучения я нашёл, что биндинг там реализован очень просто. Тупо проходимся по всем элементам, к которым прибинжены значения, создаём для них листенеры, и потом просто на каждый чих проверяем изменилось ли значение, и если да, то обновляем элемент. Там есть две основных функции $apply и $digest.
Мне кажется более правильным путь — это расчет зависимостей статически во время компиляции. Все что для этого нужно сделать:
1. Выудить информацию о зависимостях из кода.
2. Построить граф (DAG) зависимостей.
3. Произвести топологическую сортировку.
4. Сгенерить по отсортированному графу код модифицирующих зависимости.
Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
Вот код топологической сортировки который я недавно написал для собственных нужд:
Здравствуйте, VladD2, Вы писали:
VD>Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
Этот вариант просто переносит генерацию биндингов с клиента на сервер. Больше, он практически ничем не отличается, в обоих случаях нам надо анализировать DOM. А при изменении значения как ни крути придётся все биндинги проверять, тут никакие макросы не помогут. Точнее, если запретить модификацию моделей извне, то в принципе можно анализировать код модели и искать места, где происходят изменения. Но если честно, то выхлопа от подобной оптимизации будет немного, а работы, причём нетривиальной там дофига.
Ребята из AngularJS говорят, что пробежка по биндингам и так достаточно шустрая, вполне сносно работает даже на страницах с сотнями связей.
Ну и самое главное, это сейчас совсем не в приоритете. Проблему "специфичного кода" мы решили, теперь биндить можно произвольный javascript, а дальше есть и другие интересные задачи.
Здравствуйте, ionoy, Вы писали:
VD>>Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
I>Этот вариант просто переносит генерацию биндингов с клиента на сервер. Больше, он практически ничем не отличается,
Он дает статический контроль. Эдак можно говорить о том, что и вся твоя библиотека ничего недает, так как все тоже самое можно на клиентском джава-скрипте залудить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Общая информация по NemerleWeb
От:
Аноним
Дата:
24.09.12 19:42
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ionoy, Вы писали:
VD>>>Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
I>>Этот вариант просто переносит генерацию биндингов с клиента на сервер. Больше, он практически ничем не отличается,
VD>Он дает статический контроль. Эдак можно говорить о том, что и вся твоя библиотека ничего недает, так как все тоже самое можно на клиентском джава-скрипте залудить.
Влад, мне не понятна твоя любовь к статистической проверки и не любовь к доказательному программированию...
Здравствуйте, Аноним, Вы писали:
А>Влад, мне не понятна твоя любовь к статистической проверки и не любовь к доказательному программированию...
Откуда ты взял про нелюбовь? Я не люблю лишнего кода и лишних усилий. Если найдут пути доказательства корректности без дополнительных аннотация, я с удовольствием поддержку это начинание. Но глядя на примеры на современных языках вроде Агдя мне становится грустно.
Статическая же типизация не привнося оверхэда (его нивелирует вывод типов) дает вполне себе ощутимые бенефиты. То кто развивал сложный проект это отлично знает. Рефакторинг без статической типизация — это лотерея, а не программирование.
К тому же мне кажется более перспективной идея повышения надежности за счет поднятия уровня языка (ДСЛ-и и т.п.). В нем мы так же получаем возможность доказывать корректность своих программ, но при этом не увеличиваем объем программ, а наоборот сокращаем его.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Он дает статический контроль. Эдак можно говорить о том, что и вся твоя библиотека ничего недает, так как все тоже самое можно на клиентском джава-скрипте залудить.
Статический контроль даёт, да. Но что мы сможем проверить? Большая часть кода и DOM'а уже проверена на сервере, библиотека для биндинга это как накладка сверху, она собственно ничего нового в код не приносит.
Лучше уже тогда в самом трансляторе или Html макросе корректность проверять. К этому, кстати, всё и идёт, но явно не прямо сейчас, потому как это задача непростая, а из бенефитов только warning в окне output. Повторюсь, сейчас работы и без того хватает.
Здравствуйте, ionoy, Вы писали:
I>Статический контроль даёт, да. Но что мы сможем проверить?
Все. В итоге у вас должно получиться полностью статическое решение, которое проверяет все составляющие во время компиляции. Именно в этом его ценность, так как динамических аналогов выше крыши.
И кидать надо не ворнинги, а сообщения об ошибках.
Плюс зная связях статически можно генерировать более быстрый и надежный код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Все. В итоге у вас должно получиться полностью статическое решение, которое проверяет все составляющие во время компиляции. Именно в этом его ценность, так как динамических аналогов выше крыши.
Так у нас компилятор и так уже почти всё проверяет. Приведи пример хоть?
Я пока только циклические зависимости увидел, но если честно я даже не знаю, стоит ли такое пытаться отлавливать. Никто же в С#/Nemerle компиляторе этим не занимается, чем наш транслятор отличается?
Здравствуйте, ionoy, Вы писали:
I>Так у нас компилятор и так уже почти всё проверяет. Приведи пример хоть?
Зацикливание зависимостей. Наличие свойств не входящих в граф зависимостей или несвязанных подграфов в графе зависимостей.
I>Я пока только циклические зависимости увидел, но если честно я даже не знаю, стоит ли такое пытаться отлавливать. I>Никто же в С#/Nemerle компиляторе этим не занимается, чем наш транслятор отличается?
Для компиляторов статический расчет зацикливания графа зависимостей — это вычислительно-неразрешимая задача. Для отдельно взятой пары View + ViewModel — эта задача решаемая, так как есть один небольшой граф.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Общая информация по NemerleWeb
От:
Аноним
Дата:
25.09.12 16:47
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Для компиляторов статический расчет зацикливания графа зависимостей — это вычислительно-неразрешимая задача. Для отдельно взятой пары View + ViewModel — эта задача решаемая, так как есть один небольшой граф.
Какой бред... Задача либо вычислительно-неразрешимая либо вычислительно-разрешимая и от размера графа это никак не зависит... Кстати где в компиляторе требуется такая задача?
Здравствуйте, Аноним, Вы писали:
А>Какой бред... Задача либо вычислительно-неразрешимая либо вычислительно-разрешимая и от размера графа это никак не зависит... Кстати где в компиляторе требуется такая задача?
"Не может быть вычислена за полиномиальное время" тебя устроит?
Если в двух словах, то для связки View/ViewModel существует один статически-вычислимый направленный ациклический граф (даг) зависимостей. Для компилятора же таких графов получается множество и проверка отсутствия циклов в их совокупности выливается в их перемножение (мягко говоря).
В общем, модели разные по сложности, и те алгоритмы что взлетают на простой модели не взлетают на сложной.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Общая информация по NemerleWeb
От:
Аноним
Дата:
25.09.12 18:33
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>Какой бред... Задача либо вычислительно-неразрешимая либо вычислительно-разрешимая и от размера графа это никак не зависит... Кстати где в компиляторе требуется такая задача?
VD>"Не может быть вычислена за полиномиальное время" тебя устроит?
Для неоринтированного графа проверка на существование циклов линейна относительно узлов. Алгоритм — выбираем произвольный узел и обходим граф помечая вершины, если встречаем помеченную вершину, то в графе есть цикл.
Для ориентированного выбираем последовательно вершины, обходим граф,если попадаем в исходную то есть цикл. Алгоритм квадратичный. Оба полиноминальные.
VD>Если в двух словах, то для связки View/ViewModel существует один статически-вычислимый направленный ациклический граф (даг) зависимостей. Для компилятора же таких графов получается множество и проверка отсутствия циклов в их совокупности выливается в их перемножение (мягко говоря).
скорее в сумму. Зависимость чего?
VD>В общем, модели разные по сложности, и те алгоритмы что взлетают на простой модели не взлетают на сложной.
Вообще не понял причем тут сложность модели....
Здравствуйте, Аноним, Вы писали:
VD>>Если в двух словах, то для связки View/ViewModel существует один статически-вычислимый направленный ациклический граф (даг) зависимостей. Для компилятора же таких графов получается множество и проверка отсутствия циклов в их совокупности выливается в их перемножение (мягко говоря). А>скорее в сумму.
К сожалению, нет. Там, грубо, говоря выходит 4 вложенных цикла.
А>Зависимость чего?
Вычислений. Некоторые вычисления невозможно сделать до провдения других. Скажем связывание типов невозможно сделать до построения АСТ. А вычисление типов выражений до связывания. Таких связанных вычислений горы. В большинстве случаев создатели компиляторов даже не задумываются над тем, что это все набор связанных вычислений. В лучшем случае разбивают их на стадии. Результат — любой компилятор, потенциально, может начать компиляцию и никогда ее не закончить (или переполнить стек).
VD>>В общем, модели разные по сложности, и те алгоритмы что взлетают на простой модели не взлетают на сложной. А>Вообще не понял причем тут сложность модели....
Твои проблемы. Я в этом не виноват.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Общая информация по NemerleWeb
От:
Аноним
Дата:
25.09.12 19:09
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
VD>>>Если в двух словах, то для связки View/ViewModel существует один статически-вычислимый направленный ациклический граф (даг) зависимостей. Для компилятора же таких графов получается множество и проверка отсутствия циклов в их совокупности выливается в их перемножение (мягко говоря). А>>скорее в сумму. VD>К сожалению, нет. Там, грубо, говоря выходит 4 вложенных цикла.
Максимум 2 по вершинам, но даже 4 это полиномиальная сложность. Думаю можно сделать даже почти линейный(больше линейного но меньше квадрата) алгоритм.
А>>Зависимость чего? VD>Вычислений. Некоторые вычисления невозможно сделать до провдения других. Скажем связывание типов невозможно сделать до построения АСТ. А вычисление типов выражений до связывания. Таких связанных вычислений горы. В большинстве случаев создатели компиляторов даже не задумываются над тем, что это все набор связанных вычислений. В лучшем случае разбивают их на стадии. Результат — любой компилятор, потенциально, может начать компиляцию и никогда ее не закончить (или переполнить стек).
В реальности это один и тот же процесс. Создание последовательных трансформаций — языки переписывания термов на этом построены. Тот факт что компиляторы пишут не на дсл, а на языках относительно низкого уровня и породил подобный выхлоп. По хорошему даже функции это порождения данного выхлопа.
В принципе ничто не мешает до построения АСТ начать вычисления типов. Обратная ленивость, как только для функции вычислены аргументы, можно вычислить ее и т д
VD>>>В общем, модели разные по сложности, и те алгоритмы что взлетают на простой модели не взлетают на сложной. А>>Вообще не понял причем тут сложность модели.... VD>Твои проблемы. Я в этом не виноват.
Скорей всего сложность модели мы понимаем по разному. Две модели имеют равную сложность, если один тот же алгоритм примененный к обоим моделям имеет один и тот же показатель степени.
Здравствуйте, Аноним, Вы писали:
А>Максимум 2 по вершинам,
Откровенно говоря меня вообще не интересуют пустословные утверждения, и тем более не охота их оспаривать.
А> но даже 4 это полиномиальная сложность. Думаю можно сделать даже почти линейный(больше линейного но меньше квадрата) алгоритм.
Как любил говорить мой отец — "Трепач — находка для шпиёнов".
А>В реальности это один и тот же процесс. Создание последовательных трансформаций — языки переписывания термов на этом построены.
В реальности это не процесс, так как речь идет о статическом анализе который нужно совершить еще до генерации кода компилятора. В этом вся и сложность. В рантайме (т.е. когда компилятор будет компилировать код некоторого приложения) можно построить единый граф вычислений, но во время компиляции компилятора есть только отдельные разрозненные графы количеством "дофига" и проверить общую систему на зацикливание в общем случае физически невозможно. Простой пример. Граф вычислений зависит от дерева разбора. Но на стадии компиляции компилятора дерева разбора еще нет. Есть только грамматики описывающий их потенциально бесконечное множество.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Общая информация по NemerleWeb
От:
Аноним
Дата:
26.09.12 11:08
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>Максимум 2 по вершинам,
VD>Откровенно говоря меня вообще не интересуют пустословные утверждения, и тем более не охота их оспаривать.
А>> но даже 4 это полиномиальная сложность. Думаю можно сделать даже почти линейный(больше линейного но меньше квадрата) алгоритм.
VD>Как любил говорить мой отец — "Трепач — находка для шпиёнов".
Сформулируй что должен сделать алгоритм. Либо я не правильно понял либо я его напишу.
Здравствуйте, VladD2, Вы писали:
VD>Зацикливание зависимостей. Наличие свойств не входящих в граф зависимостей или несвязанных подграфов в графе зависимостей.
Имхо ты преувеличиваешь сложность связей. В большинстве случаев это:
DOM -> свойство
иногда это:
DOM -> функция
На DOM никто никогда не указывает, так что зацикливание может произойти только внутри функции. А это уже задача никаким боком биндингов не касающаяся.
Здравствуйте, ionoy, Вы писали:
I>Имхо ты преувеличиваешь сложность связей.
Из чего такой вывод? Сложны они в компиляторе. В MVVM они просты.
I>В большинстве случаев это: I>DOM -> свойство I>иногда это: I>DOM -> функция
1. Связи идут в обе стороны.
2. Это не правильный подход, так как DOM понятие аморфное. Нужно рассматривать VM как объект с входами и выходами для связывания.
I>На DOM никто никогда не указывает, так что зацикливание может произойти только внутри функции. А это уже задача никаким боком биндингов не касающаяся.
Предположим у нас есть два свойства. При изменении одного вычисляется другое. Далее мы связываем это другое свойство как источник для текстбокса (при изменении свойства меняется текстбокс). Далее текстбокс подключаем как источник для первого свойства. В итоге мы получаем цикл через "DOM". Сами по себе свойства не зациклены.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Общая информация по NemerleWeb
От:
Аноним
Дата:
27.09.12 10:44
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
А>>Сформулируй что должен сделать алгоритм. Либо я не правильно понял либо я его напишу.
VD>Что такое атрибутная грамматика знаешь?
Знаю. О чем ты теперь понял.
Здравствуйте, VladD2, Вы писали:
I>>Имхо ты преувеличиваешь сложность связей. VD>Из чего такой вывод? Сложны они в компиляторе. В MVVM они просты.
Я про это и говорю.
VD>1. Связи идут в обе стороны.
DOM элемент знает о модели, модель не знает о DOM элементе. Обновление двухстороннее, да.
VD>2. Это не правильный подход, так как DOM понятие аморфное. Нужно рассматривать VM как объект с входами и выходами для связывания.
Тут я не понял о чём ты. DOM — понятие достаточно чёткое.
VD>Предположим у нас есть два свойства. При изменении одного вычисляется другое. Далее мы связываем это другое свойство как источник для текстбокса (при изменении свойства меняется текстбокс). Далее текстбокс подключаем как источник для первого свойства. В итоге мы получаем цикл через "DOM". Сами по себе свойства не зациклены.
Ты тут предлагаешь привязать значение текстбокса к двум разным свойствам. Во первых фреймворк тебе не позволит этого сделать, а во вторых — зачем? У биндинга нет понятий вход/выход. Есть связь элемент-модель. Значения элемента и модели в любой момент времени (кроме обновления) должны быть одинаковыми.
Здравствуйте, ionoy, Вы писали:
I>DOM элемент знает о модели, модель не знает о DOM элементе. Обновление двухстороннее, да.
Это не есть гуд.
VD>>2. Это не правильный подход, так как DOM понятие аморфное. Нужно рассматривать VM как объект с входами и выходами для связывания. I>Тут я не понял о чём ты. DOM — понятие достаточно чёткое.
DOM это почти произвольная иерархия объектов. Почти каждый его элемент может служить как получателем, так и источником сигналов.
По сему это плохая модель. Но любая VM общается с View у которого должен быть четки биндинг-интерфейс. Тогда его легко проверить статически и легко сгенерирвоать код связывания.
VD>>Предположим у нас есть два свойства. При изменении одного вычисляется другое. Далее мы связываем это другое свойство как источник для текстбокса (при изменении свойства меняется текстбокс). Далее текстбокс подключаем как источник для первого свойства. В итоге мы получаем цикл через "DOM". Сами по себе свойства не зациклены. I>Ты тут предлагаешь привязать значение текстбокса к двум разным свойствам. Во первых фреймворк тебе не позволит этого сделать, а во вторых — зачем? У биндинга нет понятий вход/выход. Есть связь элемент-модель. Значения элемента и модели в любой момент времени (кроме обновления) должны быть одинаковыми.
У тебя View всегда из примитивов состоят? А как же сложные View вроде гридов или вложенных контролов? У них должна быть своя логика. И эта логика может подразумевать наличие зависимых друг от друга биндингов.
Да и вообще странно было бы рассматривать биндинги только с элементами DOM, а не с более высокоуровневыми сущностями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
I>>DOM элемент знает о модели, модель не знает о DOM элементе. Обновление двухстороннее, да. VD>Это не есть гуд.
То есть ты предлагаешь в модель пихать код биндинга?
VD>>>2. Это не правильный подход, так как DOM понятие аморфное. Нужно рассматривать VM как объект с входами и выходами для связывания. I>>Тут я не понял о чём ты. DOM — понятие достаточно чёткое. VD>DOM это почти произвольная иерархия объектов. Почти каждый его элемент может служить как получателем, так и источником сигналов.
Так и есть.
VD>По сему это плохая модель. Но любая VM общается с View у которого должен быть четки биндинг-интерфейс. Тогда его легко проверить статически и легко сгенерирвоать код связывания.
А по-поему, суть MVVM — отвязать модель от представления. Код связывания и так легко генерируется.
VD>У тебя View всегда из примитивов состоят? А как же сложные View вроде гридов или вложенных контролов? У них должна быть своя логика. И эта логика может подразумевать наличие зависимых друг от друга биндингов.
Это реализуется шаблонами.
Вот кусок кода из Samples.n, который рендерит все остальные сэмплы.
Заметь, внутри каждого отдельного сэмпла мы ничего не знаем о Samples.n, т.е. мы можем сделать каждый сэмпл отдельной страницей практически без изменения кода. Если нужна информация из SamplesPage, то можно передать его в конструкторе и биндится к нему. Имхо это самый правильный подход, который не привносит никаких дополнительных сущностей вроде биднингов.
VD>Да и вообще странно было бы рассматривать биндинги только с элементами DOM, а не с более высокоуровневыми сущностями.
По мне так это совершенно не странно. Почему ты, разрабатывая на C# или Nemerle, не реализовал себе биндинги, если они так нужны? Имхо биндинги это очень специфичная вещь, которая нужна как раз для связи между моделью и представлением.
Здравствуйте, ionoy, Вы писали:
I>То есть ты предлагаешь в модель пихать код биндинга?
Я не совсем понимаю что значит "в модель пихать код биндинга".
Биндинги должны быть описаны для контролов. Есть набор предопределенных контролов вроде текстовых полей, комбов и т.е., а есть контролы/вьюхи которые предоставляют более сложную логику. Вот у таких контролов нужно декларировать точки привязки и описывать их взаимосвязь. Ну, и при привыязке к таким точкам внутри вьюх (в которые вложены эти вьюх-контролы) проверять правильность привязок и генерировать код их поддержки (если нужно).
VD>>По сему это плохая модель. Но любая VM общается с View у которого должен быть четки биндинг-интерфейс. Тогда его легко проверить статически и легко сгенерирвоать код связывания. I>А по-поему, суть MVVM — отвязать модель от представления. Код связывания и так легко генерируется.
Ты как-то странно понимаешь слова "отвязать модель от представления". "Отвязка" и производится путем введения биндинга.
Вот только вопрос что, с чем и как связывать.
VD>>У тебя View всегда из примитивов состоят? А как же сложные View вроде гридов или вложенных контролов? У них должна быть своя логика. И эта логика может подразумевать наличие зависимых друг от друга биндингов. I>Это реализуется шаблонами. I>Вот кусок кода из Samples.n, который рендерит все остальные сэмплы.
I>
Шаблоны и выполняют роль контролов. Вопрос только, насколько типизирован интерфейс шаблона?
I>Заметь, внутри каждого отдельного сэмпла мы ничего не знаем о Samples.n, т.е. мы можем сделать каждый сэмпл отдельной страницей практически без изменения кода. Если нужна информация из SamplesPage, то можно передать его в конструкторе и биндится к нему. Имхо это самый правильный подход, который не привносит никаких дополнительных сущностей вроде биднингов.
Эти сущности и позволили бы делать четкую (декларированную) связь.
VD>>Да и вообще странно было бы рассматривать биндинги только с элементами DOM, а не с более высокоуровневыми сущностями. I>По мне так это совершенно не странно. Почему ты, разрабатывая на C# или Nemerle, не реализовал себе биндинги, если они так нужны? Имхо биндинги это очень специфичная вещь, которая нужна как раз для связи между моделью и представлением.
Первое что хочется заметить — это прочность твоей логики. Какой смысл пытаться обосновывать идеологию своего решения наличием или отсутствием чего-то где-то? Недавно ты так же обосновывал полную ненужность применения реактивной модели тем, что в ASP.NET MVC ее нет, а все ее используют.
Второе — биндинги не нужны сами по себе. Это часть реактивной модели. Если я возьмусь использовать реактивную модель, то нечто вроде биндингов я обязательно ввиду. Возможно они не будут присутствовать как отдельная сущность, а будут выражаться присвоением или именем свойства в неком теге, но они будут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Шаблоны и выполняют роль контролов. Вопрос только, насколько типизирован интерфейс шаблона?
Шаблон это прититив для вставки одной страницы в другую. Типизированы они точно так же как и основная страница.
I>>Заметь, внутри каждого отдельного сэмпла мы ничего не знаем о Samples.n, т.е. мы можем сделать каждый сэмпл отдельной страницей практически без изменения кода. Если нужна информация из SamplesPage, то можно передать его в конструкторе и биндится к нему. Имхо это самый правильный подход, который не привносит никаких дополнительных сущностей вроде биднингов. VD>Эти сущности и позволили бы делать четкую (декларированную) связь.
То есть ты неявно хочешь дать модели знать, что её сейчас используют в Samples.n? А если я её ещё в 5 разных страницах вставляю? Как по твоему будет выглядеть код для работы с этими биндингами?
I>>По мне так это совершенно не странно. Почему ты, разрабатывая на C# или Nemerle, не реализовал себе биндинги, если они так нужны? Имхо биндинги это очень специфичная вещь, которая нужна как раз для связи между моделью и представлением. VD>Первое что хочется заметить — это прочность твоей логики. Какой смысл пытаться обосновывать идеологию своего решения наличием или отсутствием чего-то где-то? Недавно ты так же обосновывал полную ненужность применения реактивной модели тем, что в ASP.NET MVC ее нет, а все ее используют.
Если я не ошибаюсь, я нигде не говорил, что реактивная модель не нужна. Более того, ещё когда только появился KnockoutJS я делал на нём сайты и был доволен. Скорее всего я говорил о том, что это не основной инструмент веб разработки, так я и сейчас так считаю. Реактивность нужна далеко не всем и далеко не всегда.
VD>Второе — биндинги не нужны сами по себе. Это часть реактивной модели. Если я возьмусь использовать реактивную модель, то нечто вроде биндингов я обязательно ввиду. Возможно они не будут присутствовать как отдельная сущность, а будут выражаться присвоением или именем свойства в неком теге, но они будут.
Так и у нас биндинги введены на заднем фоне. Но зачем из кода модели указывать на ноду в DOM'е я всё равно не понимаю. Как ты представляешь себе использование этого всего? И главное, какой от этого профит?
Здравствуйте, ionoy, Вы писали:
VD>>Шаблоны и выполняют роль контролов. Вопрос только, насколько типизирован интерфейс шаблона? I>Шаблон это прититив для вставки одной страницы в другую.
"Прототип"? Не понял написанного.
I>Типизированы они точно так же как и основная страница.
Так они у тебя типизированы или нет?
I>То есть ты неявно хочешь дать модели знать, что её сейчас используют в Samples.n? А если я её ещё в 5 разных страницах вставляю? Как по твоему будет выглядеть код для работы с этими биндингами?
Биндинги это как вилка и розетка. Телевизору не нужно знать, что он вставлен в конкретную розетку. Важно, что он куда-то вставлен и что там есть электричество.
Просто наличие декларации позволяет проверить, что источник и приемник совместимы. В переводе на пример с розеткой мы знаем, что вилка и розетка одного типа, и что в сети поддерживаемое напряжение. Можно конечно просто совать провода прямо в корпус телевизора, но вот гарантии, что он не сгорит нет.
I>Если я не ошибаюсь, я нигде не говорил, что реактивная модель не нужна. Более того, ещё когда только появился KnockoutJS я делал на нём сайты и был доволен. Скорее всего я говорил о том, что это не основной инструмент веб разработки, так я и сейчас так считаю. Реактивность нужна далеко не всем и далеко не всегда.
Я обращаю твое внимание, на то что так просто нельзя мыслит. То что где-то чего-то нет еще не значит, что это не вообще не нужно. Зачастую чего-то нет по бедности или по глупости.
VD>>Второе — биндинги не нужны сами по себе. Это часть реактивной модели. Если я возьмусь использовать реактивную модель, то нечто вроде биндингов я обязательно ввиду. Возможно они не будут присутствовать как отдельная сущность, а будут выражаться присвоением или именем свойства в неком теге, но они будут. I>Так и у нас биндинги введены на заднем фоне.
Вот именно, что на заднем фоне.
I>Но зачем из кода модели указывать на ноду в DOM'е я всё равно не понимаю.
А я не понимаю откуда ты взял, что я это предлагаю. Я говорю о том, что хорошо бы абстрагировать вьюхи до эдаких черных ящиков с точками связывания.
I>Как ты представляешь себе использование этого всего? И главное, какой от этого профит?
Полный статический контроль и возможность работать на более высоком уровне нежели DOM.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>"Прототип"? Не понял написанного.
Примитив, а не прототип. Да и то, не примитив, а скорее вид биндинга.
I>>Типизированы они точно так же как и основная страница. VD>Так они у тебя типизированы или нет?
Конечно. Только почему-то интеллисенс не работает, видимо нужна твоя помощь. Ошибки подчёркивает и показывает корректно.
...
Посмотри, если будет время, как там сейчас сделано. Вьюх, как отдельных сущностей у нас пока не намечается, я об этом уже говорил. Хорошо это или плохо, скоро будет видно.
То, что ты предлагаешь, это вроде duck typing для представлений. Мол если есть такие-то свойства, то бинди. Но в таком случае вылезает много новых проблем, например с типами. В представлении же не будешь указывать какого типа должно быть поле Value, которое ты прибиндил к инпуту. Даже если забить на это, то опять же, в чём профит? Обычно шаблон пишется под конкретную модель, так просто удобнее.
Ну и с биндингами я так и не понял, как они помогут в коде? Сейчас вроде всё красиво связано, что ещё нужно? Статический контроль, судя по всему, даст только проверку на зацикливания, но, если честно это не тот аргумент, из-за которого я решусь всё переписывать.
Здравствуйте, ionoy, Вы писали:
I>Конечно. Только почему-то интеллисенс не работает, видимо нужна твоя помощь. Ошибки подчёркивает и показывает корректно.
Что нужно сделать чтобы все это дело собрать?
I>Посмотри, если будет время, как там сейчас сделано. Вьюх, как отдельных сущностей у нас пока не намечается, я об этом уже говорил. Хорошо это или плохо, скоро будет видно.
Вы NemerleWeb на практике где-то использовать собираетесь?
I>То, что ты предлагаешь, это вроде duck typing для представлений. Мол если есть такие-то свойства, то бинди.
Похоже мы не понимаем друг-друга. Я никакой утиной типизации не подразумевал. Наоборот явно прописывать, что у модели есть такие-то точки связывания.
ЗЫ
В общем, вам нужно попробовать фрэймворк в реальных боевых условиях. Тогда многое станет ясным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Что нужно сделать чтобы все это дело собрать?
Нужно установить ASP.NET MVC 3, вроде как больше ничего.
I>>Посмотри, если будет время, как там сейчас сделано. Вьюх, как отдельных сущностей у нас пока не намечается, я об этом уже говорил. Хорошо это или плохо, скоро будет видно. VD>Вы NemerleWeb на практике где-то использовать собираетесь?
Да, сейчас обсуждаем детали.
VD>В общем, вам нужно попробовать фрэймворк в реальных боевых условиях. Тогда многое станет ясным.
Именно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ionoy, Вы писали:
I>>Страница проекта: http://moiety.apphb.com
VD>В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.
Здравствуйте, _NN_, Вы писали:
VD>>В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.
_NN>Не совсем понял проблему. _NN>И браузер какой ?
Зайди в этот тест, нажми "Delete" и нажми "Save". Далее внимательно изучи результат.
Помнится ionoy там что-то химичил, но результат получился некрасивым. Надо бы поправить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, VladD2, Вы писали:
VD>>Зайди в этот тест, нажми "Delete" и нажми "Save". Далее внимательно изучи результат. VD>>Помнится ionoy там что-то химичил, но результат получился некрасивым. Надо бы поправить.
I>Сейчас работает? У меня вроде как всё нормально.
Глючит.
Удалить.
Сохранить.
Удалить.
при том 2 будут указаны как удаленные.
Удаленне записи после сохранения не удаляются.
Здравствуйте, Аноним, Вы писали:
А>Глючит. А>Удалить. А>Сохранить. А>Удалить.
А>при том 2 будут указаны как удаленные. А>Удаленне записи после сохранения не удаляются.
В рамках примера это ожидаемое поведение. Таски просто помечаются как удалённые, но на самом деле не удаляются. По идее сервер должен их "удалять" из базы данных и отвечать, что они реально удалены. Тогда их можно вычистить из списка.
В принципе можно пример доделать в этом плане, просто никто не заморачивался.
Извинияюсь за задержку — таков сейчас график.
I>Не совсем понятно, что ты имеешь в виду. Для одноразово показываемых страниц биндинг вообще не нужен, достаточно отрендерить шаблон. А для простых взаимодействий вроще jQuery использовать, чем подлкючать Нокаут. I>Он, как и все подобные фреймворки, как раз-таки разрабатывался с направлением на одностраничные приложения.
Нет, для одноразовых биндинг нужен, т.к. часто оно общается всё равно через ajax, а во вторых knockout предлагает темплэйтинг для списков и прочее. Я говорил о том, что долгоживущему приложению как раз важно уметь биндить разные модели (данные) на форму (котролы). Я повторюсь — тогда knockoutjs просто этого не умел. Пофиксили это или нет я не знаю, но подвижки на эту тему возникли спустя год как меня их фреймворк уже перестал интересовать как класс.
F>> Обсервации... Нужен простой и понятный линейный код. На биндинг, на анбиндинг, и на апдейт стэйта при изменении тех или иных элементов форм. I>То есть всё обновлять вручную, типа I>
I>?
Да, вручную. Только вручную в JS, а не в изначальной вьюмодели. Почему обсервации в виде knockout — зло — потому что — получив с сервера банальный json — его нужно превратить в нечто особое. Соответственно тоже самое "особое" можно представить в виде того что ты указал, но для JS.
I>В нашем фреймворке нет отдельных примитивов для биндинга, код такой же, как и для любого другого приложения. Привязывается это всё с помощью "магии" по типу AngularJS.
Да я не против, и не критикую. Магия где-то должна происходить. Почему бы ей не происходить на сервере и не генерировать какой-то код который бы всё это связывал, без сторонних ангуларов?
F>> Иначе говоря простые старые добрые "винформс" только в другой оболочке. Как бы это не было противно — этот подход работает везде, хоть в вебе — хоть в винформах. I>WinForms — это далеко не "простой и понятный линейный код".
Смотря на каких примерах. На примере FullName = FirstName + LastName -> простой и понятный.
F>> AngularJS — вот недавно столкнулись, что создаёт жестоки утечки в памяти бразера (Chrome). В принципе повторяется — но разобраться — почти невозможно. Да и собственно уже новая версия ангулара вышла — а воз и ныне там. I>Ну это проблема не идеологии, а текущей реализации. Если там действительно есть где-то утечка, то её наверняка поправят. Народ там очень толковый.
Я и не говорил, что проблема идеологии. Долго правят просто, или вообще забили. Ну и страшновато юзать вещь которая не поддаётся контролю (имеется ввиду что непонятно как поправить баг и видимо не у меня одного). При этом всём, такие же самые задачи я решал более простыми способами, может и не так красиво — но на предмет утечек тестировал с пристрастием. Итого — привязки к лишним фреймворкам я послал в топку, для себя, — навсегда. Т.е. knockoutjs/angularjs — клёвые штуки, но всё равно — они просто неизбежное зло, пока с ними возникают такие проблемы. Вот с google-closure кстати никаких таких проблем нет и близко, хотя он и монстр.
F>> Я лишь кидаю мысь — что вся эта реактивность "там" в JS — имхо, — не нужна. Она нужна в описании модели и всё. Реализовать её — скорее всего дело техники. I>Что значит в описании модели?
Имел ввиду что ViewModel описываясь вся на сервере, сервером может быть представлена в любой код, очень даже лапшеобразный, лиж бы это было оправдано.
Я не призываю отказываться от каких-либо то фреймворков, просто закинул идею о том, что может это всё можно сделать более традиционным способом. Сама по себе реактивность никуда не девается.
Хотя это опять таки — кому она вообще нужна.
Здравствуйте, fddima, Вы писали:
F> Нет, для одноразовых биндинг нужен, т.к. часто оно общается всё равно через ajax, а во вторых knockout предлагает темплэйтинг для списков и прочее. Я говорил о том, что долгоживущему приложению как раз важно уметь биндить разные модели (данные) на форму (котролы). Я повторюсь — тогда knockoutjs просто этого не умел. Пофиксили это или нет я не знаю, но подвижки на эту тему возникли спустя год как меня их фреймворк уже перестал интересовать как класс.
Не нужен там биндинг, достаточно client-side templates. Да и без них легко обойтись, даже меньше проблем будет.
Что значит биндить разные модели на форму? Разве сейчас этого нет?
F> Да, вручную. Только вручную в JS, а не в изначальной вьюмодели. Почему обсервации в виде knockout — зло — потому что — получив с сервера банальный json — его нужно превратить в нечто особое. Соответственно тоже самое "особое" можно представить в виде того что ты указал, но для JS.
Даже в KnockoutJS это не проблема, есть mapping plugin. Получил данные, вызвал на них функцию, и всё — они готовы к биндингу.
А уж у нас даже этого не надо, любые сырые данные будут прибинжены.
I>>В нашем фреймворке нет отдельных примитивов для биндинга, код такой же, как и для любого другого приложения. Привязывается это всё с помощью "магии" по типу AngularJS. F> Да я не против, и не критикую. Магия где-то должна происходить. Почему бы ей не происходить на сервере и не генерировать какой-то код который бы всё это связывал, без сторонних ангуларов?
Тогда приходящие с сервера не будут чистым JSON. Имхо лучше иметь один инструмент, который работает с любыми данными, чем каждый раз эти данные видоизменять.
I>>WinForms — это далеко не "простой и понятный линейный код". F> Смотря на каких примерах. На примере FullName = FirstName + LastName -> простой и понятный.
Ну так это же никаким боком к WinForms не относится. Тебе надо с контролами работать и при этом синхронизировать их с моделью. Если у тебя есть биндинг, то шаг синхронизации не нужен.
F>>> AngularJS — вот недавно столкнулись, что создаёт жестоки утечки в памяти бразера (Chrome). В принципе повторяется — но разобраться — почти невозможно. Да и собственно уже новая версия ангулара вышла — а воз и ныне там. I>>Ну это проблема не идеологии, а текущей реализации. Если там действительно есть где-то утечка, то её наверняка поправят. Народ там очень толковый. F> Я и не говорил, что проблема идеологии. Долго правят просто, или вообще забили. Ну и страшновато юзать вещь которая не поддаётся контролю (имеется ввиду что непонятно как поправить баг и видимо не у меня одного). При этом всём, такие же самые задачи я решал более простыми способами, может и не так красиво — но на предмет утечек тестировал с пристрастием. Итого — привязки к лишним фреймворкам я послал в топку, для себя, — навсегда. Т.е. knockoutjs/angularjs — клёвые штуки, но всё равно — они просто неизбежное зло, пока с ними возникают такие проблемы. Вот с google-closure кстати никаких таких проблем нет и близко, хотя он и монстр.
Ты хоть покажи где утечка возникает, а то пока это пустые слова. У AngularJS огромное комьюнити, и я сомневаюсь, что там реально есть баги-шоустопперы.
I>>Что значит в описании модели? F> Имел ввиду что ViewModel описываясь вся на сервере, сервером может быть представлена в любой код, очень даже лапшеобразный, лиж бы это было оправдано.
Тогда теряется возможность работать с любыми данными, а веб приложения сейчас частенько ходят за ними на сервера, отличные от хоста.
F> Я не призываю отказываться от каких-либо то фреймворков, просто закинул идею о том, что может это всё можно сделать более традиционным способом. Сама по себе реактивность никуда не девается. F> Хотя это опять таки — кому она вообще нужна.
Ты же сам привёл код FullName = FirstName + LastName. В традиционных фреймворках он не работает, а в нашем — вполне.
Здравствуйте, ionoy, Вы писали:
I>Не нужен там биндинг, достаточно client-side templates. Да и без них легко обойтись, даже меньше проблем будет. I>Что значит биндить разные модели на форму? Разве сейчас этого нет?
Где нужен биндинг, а где темплейтинг — это уже выбор разработчика. Темплейты тоже биндятся собственно. Когда я смотрел knockoutjs — возможности остановить созданыые биндинги — было невозможно. Теперь судя по всему это уже можно, но я это уже лично не проверял, — нашлись более простые механизмы (и для более простых случаев).
I>Тогда приходящие с сервера не будут чистым JSON. Имхо лучше иметь один инструмент, который работает с любыми данными, чем каждый раз эти данные видоизменять.
Ну так клиентский код (отображающий эти данные) — вполне себе генерабелен. С помощью любой магии. Чистый JSON никуда и не должен деваться.
I>Ну так это же никаким боком к WinForms не относится. Тебе надо с контролами работать и при этом синхронизировать их с моделью. Если у тебя есть биндинг, то шаг синхронизации не нужен.
Биндинг — это и есть синхронизация. Если ещё при этом биндинг можно остановить / а затем стартануть биндинг на основе уже других данных — то это то что нужно.
I>Ты хоть покажи где утечка возникает, а то пока это пустые слова. У AngularJS огромное комьюнити, и я сомневаюсь, что там реально есть баги-шоустопперы. angular js issue 1313. То, с чем столкнулись мы — возможно связано с этим, возможно нет. Пока непонятно. Важно, что понять где проблема очень тяжело. И это очень критично для long-living apps, хотя не так критично для остальных. Я думаю это вскоре пофиксится, но пока вроде прогресса нет.
F>> Имел ввиду что ViewModel описываясь вся на сервере, сервером может быть представлена в любой код, очень даже лапшеобразный, лиж бы это было оправдано. I>Тогда теряется возможность работать с любыми данными, а веб приложения сейчас частенько ходят за ними на сервера, отличные от хоста.
Хм. Ну веб приложения частенько ходят за определенными данными и на определенные сервера. И ожидают от них чего-то конкретного, а не любых данных же ж.
F>> Я не призываю отказываться от каких-либо то фреймворков, просто закинул идею о том, что может это всё можно сделать более традиционным способом. Сама по себе реактивность никуда не девается. F>> Хотя это опять таки — кому она вообще нужна. I>Ты же сам привёл код FullName = FirstName + LastName. В традиционных фреймворках он не работает, а в нашем — вполне.
Выделенное — это было утверждение — "не кому она вообще нафиг впала?" — а реактивность — это хорошо, для тех, кому она нужна.
Здравствуйте, fddima, Вы писали:
F> Где нужен биндинг, а где темплейтинг — это уже выбор разработчика. Темплейты тоже биндятся собственно. Когда я смотрел knockoutjs — возможности остановить созданыые биндинги — было невозможно. Теперь судя по всему это уже можно, но я это уже лично не проверял, — нашлись более простые механизмы (и для более простых случаев).
Что значит остановить биндинги? Заставить перестать следить за обновлениями?
I>>Тогда приходящие с сервера не будут чистым JSON. Имхо лучше иметь один инструмент, который работает с любыми данными, чем каждый раз эти данные видоизменять. F> Ну так клиентский код (отображающий эти данные) — вполне себе генерабелен. С помощью любой магии. Чистый JSON никуда и не должен деваться.
То есть ты предлагаешь генерировать код, который будет следить за обновлениями? Как это проще, чем один раз написать тот-же nweb.js, и дать ему следить за всем?
F> Биндинг — это и есть синхронизация. Если ещё при этом биндинг можно остановить / а затем стартануть биндинг на основе уже других данных — то это то что нужно.
Не понимаю, зачем останавливать, если можно просто написать Model = GetNewModel()
I>>Ты хоть покажи где утечка возникает, а то пока это пустые слова. У AngularJS огромное комьюнити, и я сомневаюсь, что там реально есть баги-шоустопперы. F> angular js issue 1313. То, с чем столкнулись мы — возможно связано с этим, возможно нет. Пока непонятно. Важно, что понять где проблема очень тяжело. И это очень критично для long-living apps, хотя не так критично для остальных. Я думаю это вскоре пофиксится, но пока вроде прогресса нет.
Хах, спасибо. Исправил у нас аналогичный баг Хром нужно подтолкнуть к освобождению памяти с помощью delete (хотя на самом деле delete предназначается для другого)
F>>> Имел ввиду что ViewModel описываясь вся на сервере, сервером может быть представлена в любой код, очень даже лапшеобразный, лиж бы это было оправдано. I>>Тогда теряется возможность работать с любыми данными, а веб приложения сейчас частенько ходят за ними на сервера, отличные от хоста. F> Хм. Ну веб приложения частенько ходят за определенными данными и на определенные сервера. И ожидают от них чего-то конкретного, а не любых данных же ж.
Ну если ты опишешь данные в виде классов, то фреймворк, конечно сможет сгенерировать биндеры для них. Только я в любом случае не вижу смысла, ведь подход со сторонним биндером и мощнее и проще.
F> Выделенное — это было утверждение — "не кому она вообще нафиг впала?" — а реактивность — это хорошо, для тех, кому она нужна.
Согласен, реактивность нужна далеко не всегда. Но если она включена по дефолту, то от этого тоже никому хуже не будет, вдруг понадобится в будущем
Здравствуйте, fddima, Вы писали:
F> angular js issue 1313. То, с чем столкнулись мы — возможно связано с этим, возможно нет. Пока непонятно. Важно, что понять где проблема очень тяжело. И это очень критично для long-living apps, хотя не так критично для остальных. Я думаю это вскоре пофиксится, но пока вроде прогресса нет.
Кстати, по хорошему это баг не фреймворка, а сборщика мусора у Хрома. Как минимум в нашем коде ссылок на старые данные не оставалось, и то что приходится вызывать на них delete, это скорее хак, чтобы обойти недоработку GC.
Слепил вместе — это всё об одном:
I>Что значит остановить биндинги? Заставить перестать следить за обновлениями? I>То есть ты предлагаешь генерировать код, который будет следить за обновлениями? Как это проще, чем один раз написать тот-же nweb.js, и дать ему следить за всем? I>Не понимаю, зачем останавливать, если можно просто написать Model = GetNewModel()
На предложение это слабо похоже, но в принципе да — о нечто таком я и говорю. Ну может и проще написать nweb.js. Хотя что это я пока не знаю.
Остановить биндинги — значит, что после остановки — биндящий фреймворк перестал содержать ссылки на элементы (если таковые есть) / подписки на эвенты. Ну это разумеется зависит от фреймворка. Это нужно для высвобождения "формы" на которую что-то биндится. В случае если она остаётся всегда загруженной — тогда достаточно иметь возможности get/set новой модели.
I>Хах, спасибо. Исправил у нас аналогичный баг Хром нужно подтолкнуть к освобождению памяти с помощью delete (хотя на самом деле delete предназначается для другого)
Я чего-то пропустил — чего высвобождать с помощью delete?
I>Ну если ты опишешь данные в виде классов, то фреймворк, конечно сможет сгенерировать биндеры для них. Только я в любом случае не вижу смысла, ведь подход со сторонним биндером и мощнее и проще.
Ну в итоге — тебе виднее. А сложно переключится между фреймворками (в текущей эпостасии)?
Здравствуйте, fddima, Вы писали:
F> На предложение это слабо похоже, но в принципе да — о нечто таком я и говорю. Ну может и проще написать nweb.js. Хотя что это я пока не знаю.
nweb.js — это замена KnockoutJS, которую пришлось написать в виду ограниченности последнего.
F> Остановить биндинги — значит, что после остановки — биндящий фреймворк перестал содержать ссылки на элементы (если таковые есть) / подписки на эвенты. Ну это разумеется зависит от фреймворка. Это нужно для высвобождения "формы" на которую что-то биндится. В случае если она остаётся всегда загруженной — тогда достаточно иметь возможности get/set новой модели.
Это всё делается автоматически на шаге инвалидации. Старые данные и элементы удаляются, новые добавляются. В nweb нет понятия observable, всё данные POJO.
I>>Хах, спасибо. Исправил у нас аналогичный баг Хром нужно подтолкнуть к освобождению памяти с помощью delete (хотя на самом деле delete предназначается для другого) F> Я чего-то пропустил — чего высвобождать с помощью delete?
Короче там суть в том, что на шаге инвалидации происходит проверка
if(binding.oldValue !== newValue) {
binding.apply(newValue);
binding.oldValue = newValue; <-- По идее этого должно хватать, для того, чтобы GC мог подчистить память.
// Но экспериментальным путём было выяснено, что необходимо сделать delete binding.oldValue, чтобы совсем удалить поле из объекта.
// Видимо это подталкивает хром на освобождение памяти
}
I>>Ну если ты опишешь данные в виде классов, то фреймворк, конечно сможет сгенерировать биндеры для них. Только я в любом случае не вижу смысла, ведь подход со сторонним биндером и мощнее и проще. F> Ну в итоге — тебе виднее. А сложно переключится между фреймворками (в текущей эпостасии)?
Ну у нас сейчас только один биндящий фреймворк — nweb.js. С нокаута на него было в принципе не сложно перейти, код даже стал проще. Если раньше транслятору приходилось иметь в виду особенности нокаута, то теперь мы можем генерировать в нормальный яваскрипт, без оглядок на биндинг.
Здравствуйте, ionoy, Вы писали:
I>nweb.js — это замена KnockoutJS, которую пришлось написать в виду ограниченности последнего. I>Это всё делается автоматически на шаге инвалидации. Старые данные и элементы удаляются, новые добавляются. В nweb нет понятия observable, всё данные POJO. I>Ну у нас сейчас только один биндящий фреймворк — nweb.js. С нокаута на него было в принципе не сложно перейти, код даже стал проще. Если раньше транслятору приходилось иметь в виду особенности нокаута, то теперь мы можем генерировать в нормальный яваскрипт, без оглядок на биндинг.
Пполучился разговор глухого со слепым. Извиняюсь.
F>> Я чего-то пропустил — чего высвобождать с помощью delete? I>Короче там суть в том, что на шаге инвалидации происходит проверка
Ну я больше про пример из issue на довольно простом ng-repeat. Ведёт пока что себя это так, что остаются ссылки на DOM из JS. Хотя пока понять почему не могу.
Здравствуйте, fddima, Вы писали:
F>>> Я чего-то пропустил — чего высвобождать с помощью delete? I>>Короче там суть в том, что на шаге инвалидации происходит проверка F> Ну я больше про пример из issue на довольно простом ng-repeat. Ведёт пока что себя это так, что остаются ссылки на DOM из JS. Хотя пока понять почему не могу.
А это оно и есть, код я привёл из внутренностей фреймворка. Не уверен, что у них абсолютно такая же проблема, так как их кода я не видел. Но симптомы те же, так что рискну предположить, что и решается аналогично.
Здравствуйте, ionoy, Вы писали:
I>А это оно и есть, код я привёл из внутренностей фреймворка. Не уверен, что у них абсолютно такая же проблема, так как их кода я не видел. Но симптомы те же, так что рискну предположить, что и решается аналогично. I>Я здесь
Здравствуйте, fddima, Вы писали:
F> Вот это — решает проблему в Хроме. Я не знаю насколько это правильно. Так, просто попробовал.
Кстати, насчёт бага я поспешил. Сейчас убрал "фикс" с delete и запустил страницу снова. Оказалось, что память растёт только тогда, когда открыт developer tools. Если его закрыть, то всё корректно вычищается.
Так что, возможно, у нас и не было этой проблемы.
F> Вот это — решает проблему в Хроме. Я не знаю насколько это правильно. Так, просто попробовал.
Даже не знаю как это может помочь, ты ведь обнуляешь ссылки на другие объекты, а не на удаляемый. Разве чтогде-то есть циклические зависимости.
С другой стороны, если это действительно помогло, то закинул бы этот пример разработчикам, а они уже разбируться, что к чему.
Здравствуйте, ionoy, Вы писали:
I>Кстати, насчёт бага я поспешил. Сейчас убрал "фикс" с delete и запустил страницу снова. Оказалось, что память растёт только тогда, когда открыт developer tools. Если его закрыть, то всё корректно вычищается. I>Так что, возможно, у нас и не было этой проблемы.
В консоль объекты пишешь? Консоль на них ссылки держит.
Здравствуйте, fddima, Вы писали:
I>>Кстати, насчёт бага я поспешил. Сейчас убрал "фикс" с delete и запустил страницу снова. Оказалось, что память растёт только тогда, когда открыт developer tools. Если его закрыть, то всё корректно вычищается. I>>Так что, возможно, у нас и не было этой проблемы. F> В консоль объекты пишешь? Консоль на них ссылки держит.
Нет, консоль пустая.
Здравствуйте, ionoy, Вы писали:
I>Даже не знаю как это может помочь, ты ведь обнуляешь ссылки на другие объекты, а не на удаляемый. Разве чтогде-то есть циклические зависимости.
Ну и да и нет. V8 GC в отношении нативных объектов не очень умный. Но я пробовал форсировать сборку мусора и она почти ничего не давала, поэтому там точно остаются ссылки на DOM.
I>С другой стороны, если это действительно помогло, то закинул бы этот пример разработчикам, а они уже разбируться, что к чему.
В issue я запихнул. На реальном ничем я ещё это пока не пробовал. Но примеру из issue это жестко помогает.
Re: Общая информация по NemerleWeb
От:
Аноним
Дата:
01.11.12 08:14
Оценка:
Здравствуйте, ionoy, Вы писали:
Не корректно рпботает пример с цветным прямоугольником, при выборе цвета Ред поля ввода не скрываются
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, ionoy, Вы писали: А>Не корректно рпботает пример с цветным прямоугольником, при выборе цвета Ред поля ввода не скрываются
Сейчас постоянно меняется код транслятора и сопутствующего окружения, поэтому следить за тем, чтобы все сэмплы работали не всегда получается.
Будет время, глянем.
Здравствуйте, Ikemefula, Вы писали:
I>Есть ли поддежка CommonJS и AMD модулей ?
Нет. Если есть конкретные предложения, как эту поддержку добавить, то вполне вероятно, что сделаем.
I>Есть ли способ использования js-библиотек, опять же ввиде CommonJS и AMD ?
Пока что только в виде:
js <#
...javascript code here...
#>;
В принципе можно добавить javascript парсер, который будет автоматически добавлять обёртки для API сторонних библиотек, но пока за это не брались.
Сейчас доделываем поддержку PEG, это должно быть достаточно круто.
Здравствуйте, Ziaw, Вы писали:
Z>Можно глупый вопрос? А нафига? Я конечно понимаю, что парсеры на js теперь писать легко и приятно, а что парсить-то будем?
Первоначально нужен был парсер Markdown, прикинули, что было бы круто для этого прикрутить PEG. В процессе исправили много недоработок, и сделали транслятор более универсальным.
Для чего реально может ещё понадобится пока неизвестно, но осознание наличия такого мощного инструмента очень даже радует.
Здравствуйте, WolfHound, Вы писали:
WH>Вам еще вот что нужно сделать: WH>Сейчас вы генерируете код прямо в страницу. Это плохо. Ибо страница раздувается до безобразия. WH>ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого. WH>Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится. WH>Таким образом, можно будет значительно сократить трафик при небольших изменениях в больших приложениях.
Да, мы об этом уже думали. Там вместе с этим надо будет некоторые инфраструктурные изменения сделать, поэтому пока откладывали.
Сваливать всё в один запрос конечно никуда не годится
Здравствуйте, WolfHound, Вы писали:
WH>ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого. WH>Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится.
Круто! А что делать если хэши совпадут? Они ведь по определению не уникальны.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Круто! А что делать если хэши совпадут? Они ведь по определению не уникальны.
SHA1 совпадет? А ты знаешь, что GIT использует SHA1 в качестве первичного ключа?
Что будет, если у двух исходных файлов SHA1 совпадет? Это же репозиторий GIT'а сломается...
Короче на данный момент не известно ни одной коллизии SHA1.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>SHA1 совпадет?
Хэш есть хэш. Вероятность может и низка, но она 100% есть.
WH>А ты знаешь, что GIT использует SHA1 в качестве первичного ключа?
Я в детали не вдавался. Если это так и никаких дополнительных действий не предпринимается, то вероятность дублирования есть. Возможно они тупо добавляют время комита, что делает вероятность совпадения совсем мизерной.
WH>Что будет, если у двух исходных файлов SHA1 совпадет? Это же репозиторий GIT'а сломается... WH>Короче на данный момент не известно ни одной коллизии SHA1.
А их кто-то проверяет?
В общем, хэш есть хэш. Уникальным его можно считать разве что условно. А изменение файла можно отслеживать и по времени или сочетании хэша и времени.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Хэш есть хэш. Вероятность может и низка, но она 100% есть.
Спасибо кэп.
VD>Я в детали не вдавался. Если это так и никаких дополнительных действий не предпринимается, то вероятность дублирования есть. Возможно они тупо добавляют время комита, что делает вероятность совпадения совсем мизерной.
Ничего они дополнительно не делают.
И HG тоже живет на SHA1. И тоже ничего дополнительно не делает.
7.11. What about hash collisions? What about weaknesses in SHA1?
The SHA1 hashes are large enough that the odds of accidental hash collision are negligible for projects that could be handled by the human race. The known weaknesses in SHA1 are currently still not practical to attack, and Mercurial will switch to SHA256 hashing before that becomes a realistic concern.
VD>А их кто-то проверяет?
Проверяют. Еще как проверяют. Толпы криптографов только этим и занимаются.
VD>В общем, хэш есть хэш. Уникальным его можно считать разве что условно. А изменение файла можно отслеживать и по времени или сочетании хэша и времени.
Время не нужно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>В общем, хэш есть хэш. Уникальным его можно считать разве что условно. А изменение файла можно отслеживать и по времени или сочетании хэша и времени.
SHA-1 алгоритм генерирует 160-битное хеш-значение.
2^160 ~= 1.46*10^48
Т.е. вероятность того, что два разных документа будут иметь одинаковый хэш равна ~10^(-48).
Оценим вероятность падения астероида на сервер.
Если верить этому, то частота падения астероида с поперечником >50 метров — раз в 1000 лет.
Допустим, что площадь сервера порядка 1м^2.
Упростим задачу — оценим вероятность того, что за 1000 лет астероид упадет на сервер, причем его центр масс окажется внутри поверхности сервера.
Площадь Земли равна ~5*10^14 м^2. Т.е. вероятность порядка 10^(-15).
Итого, вероятность падения астероида на сервер за 1000 лет примерно в 10^33 выше, чем вероятность того, что два разных документа будут иметь одинаковый SHA-1 хэш.
PS Я нигде не ошибся?
PPS На правах шутки
Re[6]: Общая информация по NemerleWeb
От:
Аноним
Дата:
09.11.12 21:43
Оценка:
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
A>PS Я нигде не ошибся? A>PPS На правах шутки
Ошибся, при вычислениях коллизий хеша берут корень из числа значений т.е примерно 10^24 (парадокс шапок)
Хеш относильно легко подделывается, а генерация пар текстов имеющих один и тот же хеш плевое дело давно уже....
но если злой умысел можно исключить, то винт сгорит всяко быстрее даи сервер сменят...
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, artelk, Вы писали:
A>>PS Я нигде не ошибся? A>>PPS На правах шутки А>Ошибся, при вычислениях коллизий хеша берут корень из числа значений т.е примерно 10^24 (парадокс шапок) А>Хеш относильно легко подделывается, а генерация пар текстов имеющих один и тот же хеш плевое дело давно уже....
Но это другая задача, она проще, чем подобрать другой текст с тем же хэшем.
А>но если злой умысел можно исключить, то винт сгорит всяко быстрее даи сервер сменят...
Был один js, его как-то поменяли (без намерения сделать так, чтобы результат имел тот же хэш). Какова вероятность?
Re[8]: Общая информация по NemerleWeb
От:
Аноним
Дата:
10.11.12 05:13
Оценка:
Здравствуйте, artelk, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, artelk, Вы писали:
A>>>PS Я нигде не ошибся? A>>>PPS На правах шутки А>>Ошибся, при вычислениях коллизий хеша берут корень из числа значений т.е примерно 10^24 (парадокс шапок) А>>Хеш относильно легко подделывается, а генерация пар текстов имеющих один и тот же хеш плевое дело давно уже.... A>Но это другая задача, она проще, чем подобрать другой текст с тем же хэшем.
А>>но если злой умысел можно исключить, то винт сгорит всяко быстрее даи сервер сменят... A>Был один js, его как-то поменяли (без намерения сделать так, чтобы результат имел тот же хэш). Какова вероятность?
10^48
если у тебя много файлов таких то она растет как n^2
Здравствуйте, WolfHound, Вы писали:
VD>>Круто! А что делать если хэши совпадут? Они ведь по определению не уникальны. WH>SHA1 совпадет? А ты знаешь, что GIT использует SHA1 в качестве первичного ключа? WH>Что будет, если у двух исходных файлов SHA1 совпадет? Это же репозиторий GIT'а сломается... WH>Короче на данный момент не известно ни одной коллизии SHA1.
Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано.
Здравствуйте, <Аноним>, Вы писали:
А>Хеш относильно легко подделывается, а генерация пар текстов имеющих один и тот же хеш плевое дело давно уже....
Для SHA1? Ссылку на работу можно?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Аноним, Вы писали:
I>>Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано. А>тогда название и хеш
Это настоящее вредительство и хэппи дебаг, при разработке.
Как только сервер сгенерирует новый хеш, все наши брейкпойнты уедут в небытие. Собственно моим сообщением ниже именно эта проблема и решается.
Здравствуйте, fddima, Вы писали:
F>1. Можно в конец JS файла добавлять такой комментарий: F>
F>//@ sourceURL=my-original-name.js
F>
F>(Возможно надо его оградить переносами строк, был какой-то нюанс не помню уже). Это должно заставить дебаггер отображать этот ресурс именно с этим именем. Chrome и FF это должны поддерживать. Сам я давно этим уже не пользовался, но раньше точно работало.
Не знал, спасибо! Если это работает во ФФ и Хроме, то будет очень даже неплохо.
Здравствуйте, Ziaw, Вы писали:
Z>Надо это все абстрагировать от самого фреймворка. Сделать удобные способы для вывода на страницу, в файл при компиляции, в script bundler. Z>Самим городить этот огород с хешами не стоит, ибо оно будет навязывать идеологию и идти вразрез с текущей политикой управления скриптами в проекте. Не стоит сосредотачивать свои усилия на написании своего аналога bundler.
Это дело надо серъёзно обдумать, если есть желание помочь, то было бы неплохо. Можно в скайпе конфу создать и обсудить всё.
Нам двоим сейчас и так забот хватает — NN пилит PEG, я в этом время исправляю/дополняю транслятор. После этого можно будет подумать над правильной организацией скриптов.
Z>Offtopic: Z>Я бы посоветовал сейчас сосредоточиться на простом способе подцепить ваш функционал к готовому проекту на любом языке .net (или хотя бы C#) и на раскрутку (seo по "asp.net mvc knockoutjs").
Ну так оно так и работает. Достаточно добавить класс с атрибутом Unit и вернуть его из какого-нибудь экшена.
Z>Убежден, что технология выстрелит только при использовании оригинального knockoutjs (либо будучи 100% совместимой с ним). Я понимаю причины которые побудили создать свой велосипед. Но для популярности нужен либо http://knockoutjs.com/ и поддержка MS либо 100% совместимость с ним (и в будущем тоже). Насколько сложно сейчас вернуться на knockoutjs, пусть даже с использованием манкипатчинга?
А смысл? Никто всё равно не видит, что там под капотом творится, а Нокаут сильно ограничивает нас в трансляции. С новым биндингом у нас практически неограниченные возможности, а раньше постоянно приходилось бороться с Нокаутом, причём частенько безуспешно.
Z>P.S. у меня на сайте не подсвечивается Source, но подсвечивается Main page source.
Надо будет поправить, спс.
Здравствуйте, ionoy, Вы писали:
I>Это дело надо серъёзно обдумать, если есть желание помочь, то было бы неплохо. Можно в скайпе конфу создать и обсудить всё. I>Нам двоим сейчас и так забот хватает — NN пилит PEG, я в этом время исправляю/дополняю транслятор. После этого можно будет подумать над правильной организацией скриптов.
Что тут думать, не надо переизобретать то, что уже есть, работает и все этим пользуются.
I>Ну так оно так и работает. Достаточно добавить класс с атрибутом Unit и вернуть его из какого-нибудь экшена.
отлично
Z>>Убежден, что технология выстрелит только при использовании оригинального knockoutjs (либо будучи 100% совместимой с ним). Я понимаю причины которые побудили создать свой велосипед. Но для популярности нужен либо http://knockoutjs.com/ и поддержка MS либо 100% совместимость с ним (и в будущем тоже). Насколько сложно сейчас вернуться на knockoutjs, пусть даже с использованием манкипатчинга? I>А смысл? Никто всё равно не видит, что там под капотом творится, а Нокаут сильно ограничивает нас в трансляции. С новым биндингом у нас практически неограниченные возможности, а раньше постоянно приходилось бороться с Нокаутом, причём частенько безуспешно.
А над капотом? Биндинги те же? Принципы observable, computed? Возможность создания собственных биндингов? Насколько сложно сделать что-то не очень стандартное, типа свойства которое биндится на класс элемента, не трогая классы уже прописанные в разметке, биндинг даты на календарь? Где про все это прочитать? 95% потенциальных пользователей пробовали нокаут и знают как с ним работать, хорошо бы их не переобучать. Я пока не на 100% в этом уверен, но надо хорошо подумать над этим вопросом. Сейчас нокаут идет в шаблоне MVC проекта и людей, которые его знают становится все больше.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, ionoy, Вы писали:
I>>Это дело надо серъёзно обдумать, если есть желание помочь, то было бы неплохо. Можно в скайпе конфу создать и обсудить всё. Z>Что тут думать, не надо переизобретать то, что уже есть, работает и все этим пользуются.
Надо решить, как будут формироваться скрипты. Сохранять ли их физически на диск? (Нужно разрешение на запись, что не всегда есть) Прописывать скрипт в поле и возвращать его потом из экшена?
Может быть стоит добавить ключ в конфигурацию?
Z>А над капотом? Биндинги те же? Принципы observable, computed? Возможность создания собственных биндингов? Насколько сложно сделать что-то не очень стандартное, типа свойства которое биндится на класс элемента, не трогая классы уже прописанные в разметке, биндинг даты на календарь? Где про все это прочитать? 95% потенциальных пользователей пробовали нокаут и знают как с ним работать, хорошо бы их не переобучать. Я пока не на 100% в этом уверен, но надо хорошо подумать над этим вопросом. Сейчас нокаут идет в шаблоне MVC проекта и людей, которые его знают становится все больше.
Никаких observable или computed тут нет, это всё осталось в нокауте. Теперь у нас есть произвольный объект, например:
function User(name, age) {
this.name = name;
this.age = age;
this.greeting = function() {
return "Hello, " + name + "!";
}
}
или
var user = {
name: "Peter",
age: 43
this.greeting = function() {
return "Hello, " + name + "!";
}
};
Можно биндиться ко всему, что возвращает значение, будь то функция или поле.
При этом биндинг в HTML выглядит не так как в нокауте, а просто
<span class="greeting" class="$SomeClass">This is greeting: $(User.greeting)</span>
На данный момент, чтобы добавить класс к уже прописанным статически придётся добавлять второй атрибут class, но это просто потому что никто этим не занимался. Там немного парсер надо поправить и всё будет работать.
Здравствуйте, VladD2, Вы писали:
WH>>SHA1 совпадет? VD>Хэш есть хэш. Вероятность может и низка, но она 100% есть.
WH>>А ты знаешь, что GIT использует SHA1 в качестве первичного ключа?
VD>Я в детали не вдавался. Если это так и никаких дополнительных действий не предпринимается, то вероятность дублирования есть. Возможно они тупо добавляют время комита, что делает вероятность совпадения совсем мизерной.
Да она и так, мягко говоря, настолько около нуля, что добавление времени ничего здесь не изменит.
Слабо знаком с Веб девелопментом, но что понял при первом знакомстве — я бы убил создателей Javascript
Все-таки я приверженец статической типизации.
Есть насущный вопрос. Сумбурно но, надеюсь, главная идея будет понятна.
Надо делать программу под мобильные девайсы, очень неплохо подходит PhoneGap, так как переносима между платформами да и слишком больших наворотов в графике не предвидется. В голове витают такие мысли: есть ли возможность вашим фреймворком сделать скрипты, страницы так чтобы я их смог спокойно запихнуть в PhoneGap и наслаждаться девелопментом в Nemerle?
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, ionoy, Вы писали:
D>Слабо знаком с Веб девелопментом, но что понял при первом знакомстве — я бы убил создателей Javascript D>Все-таки я приверженец статической типизации.
Яваскрипт на самом деле очень интересный язык и для многих вещей очень удобен. Просто Немерле круче
D>Есть насущный вопрос. Сумбурно но, надеюсь, главная идея будет понятна. D>Надо делать программу под мобильные девайсы, очень неплохо подходит PhoneGap, так как переносима между платформами да и слишком больших наворотов в графике не предвидется. В голове витают такие мысли: есть ли возможность вашим фреймворком сделать скрипты, страницы так чтобы я их смог спокойно запихнуть в PhoneGap и наслаждаться девелопментом в Nemerle?
Теоретически это вполне реально. Я правда не пробовал на PhoneGap что-то делать, надо будет посмотреть. Но так как транслятор сейчас универсальный, то не составит труда генерировать какой угодно код.
Сейчас мы постоянно меняем что-то в фреймворке, поэтому нельзя закладываться на какую-либо функциональность. Ну и самое главное, кто-то должен реализовать ту часть, которая будет отвечать за PhoneGap. Если есть желание, то мы поможем всем чем сможем Прикручивать можно и сейчас начать, для этого необязательно ждать пока мы всё исправим.
Здравствуйте, ionoy, Вы писали:
D>>Здравствуйте, ionoy, Вы писали:
D>>Слабо знаком с Веб девелопментом, но что понял при первом знакомстве — я бы убил создателей Javascript D>>Все-таки я приверженец статической типизации. I>Яваскрипт на самом деле очень интересный язык и для многих вещей очень удобен. Просто Немерле круче
Да некоторые вещи интересны но, честно, извините, не люблю языков поощряющих прострел ноги Хочу чтобы ошибки искал компилятор, а не юзверь.
I>Сейчас мы постоянно меняем что-то в фреймворке, поэтому нельзя закладываться на какую-либо функциональность. Ну и самое главное, кто-то должен реализовать ту часть, которая будет отвечать за PhoneGap. Если есть желание, то мы поможем всем чем сможем Прикручивать можно и сейчас начать, для этого необязательно ждать пока мы всё исправим.
Похоже нужно реализовывать интерфейс к Cordova. Пока еще в этом дуб дубом, любая помощь приветствуется. Если тыкните пальцем куда копать — нароем. https://github.com/phonegap/phonegap
Здравствуйте, Danchik, Вы писали:
D>Похоже нужно реализовывать интерфейс к Cordova. Пока еще в этом дуб дубом, любая помощь приветствуется. Если тыкните пальцем куда копать — нароем. D>https://github.com/phonegap/phonegap
Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, Danchik, Вы писали:
D>>Похоже нужно реализовывать интерфейс к Cordova. Пока еще в этом дуб дубом, любая помощь приветствуется. Если тыкните пальцем куда копать — нароем. D>>https://github.com/phonegap/phonegap
I>Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
Если я не ошибаюсь так оно и есть (бегло глянув на содержимое).
Значит, заюзав произвольную Style Library можна начать ваять сайт с использованием вашего фрамеворка?
Здравствуйте, Danchik, Вы писали:
I>>Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
D>Если я не ошибаюсь так оно и есть (бегло глянув на содержимое). D>Значит, заюзав произвольную Style Library можна начать ваять сайт с использованием вашего фрамеворка?
В принципе да, только надо будет для начала добавить возможность генерировать файлы на жёсткий диск. Плюс нужен какой-то механизм для Master Pages.
Первое я собирался делать сразу после того, как полностью допилим PEG (что должно произойти на днях).
Ну и ещё не совсем продумали, как и куда правильней сохранять полученный код, а главное, как его потом отдавать. Хотелось бы разобраться с этим вопросом раз и на всегда, чтобы потом не вносить ломающих изменений в такую важную часть фреймворка.
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, Danchik, Вы писали:
I>>>Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
D>>Если я не ошибаюсь так оно и есть (бегло глянув на содержимое). D>>Значит, заюзав произвольную Style Library можна начать ваять сайт с использованием вашего фрамеворка?
I>В принципе да, только надо будет для начала добавить возможность генерировать файлы на жёсткий диск. Плюс нужен какой-то механизм для Master Pages. I>Первое я собирался делать сразу после того, как полностью допилим PEG (что должно произойти на днях).
Ну что ж, для меня это будет просто киллер фича
I>Ну и ещё не совсем продумали, как и куда правильней сохранять полученный код, а главное, как его потом отдавать. Хотелось бы разобраться с этим вопросом раз и на всегда, чтобы потом не вносить ломающих изменений в такую важную часть фреймворка.
Надеюсь это случится в этом году )))
Теперь вопрос, есть ли какой-то механизм задания типизированного интерфейса к жаваскрипту? Например с Cordova. Имееется ввиду что-то подобное:
namespace Cordova
{
[JsIntf]
module Camera
{
public GetPicture(success : Action<string>, error : Action<string>) : void;
{
// черт его знает что, чтобы при трансляции генерило вызов camera.getPicture(successCallback, errorCallback)
}
}
}
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Danchik, Вы писали:
D>>Теперь вопрос, есть ли какой-то механизм задания типизированного интерфейса к жаваскрипту? Например с Cordova. Имееется ввиду что-то подобное:
_NN>Макрос js вставляет строку непосредственно:
Здравствуйте, ionoy, Вы писали:
I>Реализация не нужна, методы будут один в один транслироваться. Коллбеки тоже будут работать.
Что ж замечательно, тогда это я и сам смогу реализовать
Осталось сделать генерацию сайта, чтоб он спокойно работал без сервера и дальше можна продолжать копать в этом направлении. Таким образом Nemrle невзначай попадет в нишу мобильного девелопмента!
Надеюсь на скорейшем развитии фрейворка, очень скоро буду над ним издеваться
Здравствуйте, Danchik, Вы писали:
D>Что ж замечательно, тогда это я и сам смогу реализовать D>Осталось сделать генерацию сайта, чтоб он спокойно работал без сервера и дальше можна продолжать копать в этом направлении. Таким образом Nemrle невзначай попадет в нишу мобильного девелопмента! D>Надеюсь на скорейшем развитии фрейворка, очень скоро буду над ним издеваться
Отлично! Если соберёшься что-то делать, то напиши мне или _NN_ на мыло, там уже скооперируемся.
Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн). Есть за плечами опыт в одном сайте всего лишь и охота, наконец, заюзать Немерл, поскольку толкусь на этом форуме уже год, почитываю, облизываюсь, а заюзать не особо есть где. Вопрос: если я воспользуюсь текущими наработками по NemerleWeb, это не сильно ударит по яйкам? В какой стадии проект?
Здравствуйте, Mumusan, Вы писали:
M>Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн). Есть за плечами опыт в одном сайте всего лишь и охота, наконец, заюзать Немерл, поскольку толкусь на этом форуме уже год, почитываю, облизываюсь, а заюзать не особо есть где. Вопрос: если я воспользуюсь текущими наработками по NemerleWeb, это не сильно ударит по яйкам? В какой стадии проект?
Сэмплы работают, тесты проходят.
Пока не все, но это скоро поправим.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, Mumusan, Вы писали:
M>>Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн). Есть за плечами опыт в одном сайте всего лишь и охота, наконец, заюзать Немерл, поскольку толкусь на этом форуме уже год, почитываю, облизываюсь, а заюзать не особо есть где. Вопрос: если я воспользуюсь текущими наработками по NemerleWeb, это не сильно ударит по яйкам? В какой стадии проект?
_NN>Сэмплы работают, тесты проходят. _NN>Пока не все, но это скоро поправим.
_NN>Баги описаны тут.
_NN>Вы озвучьте требования, а там будет видно подойдет или нет.
_NN>К тому же тут надо учитывать, что возможно придется править или улучшать саму библиотеку. _NN>Про компилятор я скромно промолчу
Здравствуйте, ionoy, Вы писали:
I>С тонкостями MVVM не придётся разбираться, фреймворк построен так, как будто пишешь обычный шаблон. Данные сами по себе, магическим образом обновляются по мере обновления модели в коде.
Не знаю, как другие, но мне пришлось набить несколько шишек, прежде чем я въехал в саму идеологию. Принципы просты, но для их использования мне пришлось пару-тройку хороших вьюх сделать и пару раз переделать.
Здравствуйте, Ziaw, Вы писали:
I>>С тонкостями MVVM не придётся разбираться, фреймворк построен так, как будто пишешь обычный шаблон. Данные сами по себе, магическим образом обновляются по мере обновления модели в коде.
Z>Не знаю, как другие, но мне пришлось набить несколько шишек, прежде чем я въехал в саму идеологию. Принципы просты, но для их использования мне пришлось пару-тройку хороших вьюх сделать и пару раз переделать.
Ну да, это с любой идеологией так. Но в целом MVVM достаточно лёгок в понимании.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, _NN_, Вы писали:
_NN>>Невероятными усилиями удалось транслировать PEG.
Z>Можно глупый вопрос? А нафига? Я конечно понимаю, что парсеры на js теперь писать легко и приятно, а что парсить-то будем?
К примеру можно парсить BBCode сайта RSDN и выдавать предварительный просмотр без сервера
Здравствуйте, WolfHound, Вы писали:
WH>Вам еще вот что нужно сделать: WH>Сейчас вы генерируете код прямо в страницу. Это плохо. Ибо страница раздувается до безобразия. WH>ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого. WH>Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится. WH>Таким образом, можно будет значительно сократить трафик при небольших изменениях в больших приложениях.
В общем думаем в ближайшее время заняться этой проблемой.
Надо определится, на основе чего считать хеш:
1. Некое сериализированное представление класса (все члены + PExpr методов в виде строки)
2. Исходные файлы. Тут непонятно, как их правильно доставать. В TypeBuilder они вроде как есть, но пути там указаны относительные, то есть нужно найти корневой каталог.
Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку?
Здравствуйте, ionoy, Вы писали:
I>Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку?
У вас уже всё есть.
Вы генерируете коде на жабаскрипте.
Это и есть полное представление всех значимых деталей класса, текущей версии немерла и всех макросов.
Если что-то изменится, то изменится и код. А значит и хэш.
А если код не изменится, то можно будет и старый использовать. Ибо он идентичен.
Что нам и нужно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку? WH>У вас уже всё есть.
Короче просто нужно считать хеш от содержимого генерируемого файла.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку? WH>У вас уже всё есть. WH>Вы генерируете коде на жабаскрипте. WH>Это и есть полное представление всех значимых деталей класса, текущей версии немерла и всех макросов. WH>Если что-то изменится, то изменится и код. А значит и хэш. WH>А если код не изменится, то можно будет и старый использовать. Ибо он идентичен. WH>Что нам и нужно.
Я просто подумал, что это могло бы быть неплохой оптимизацией. Всё-таки трансляция это довольно ресурсоёмкий процесс, и если есть возможность пропускать те классы, которые уже транслированы, то пересборка будет проходить быстрее. С точки зрения разработчика это достаточно важно.
Здравствуйте, ionoy, Вы писали:
I>Я просто подумал, что это могло бы быть неплохой оптимизацией. Всё-таки трансляция это довольно ресурсоёмкий процесс, и если есть возможность пропускать те классы, которые уже транслированы, то пересборка будет проходить быстрее. С точки зрения разработчика это достаточно важно.
А ты измерял?
Просто чтобы посчитать хеш с учетом всех зависимостей тебе всё равно придется сделать почти всю работу. Разве что сериализацю в жабаскрипт можно не делать. А это я думаю на фоне остального копейки.
Например, я измерял, сколько работают мои макросы. Не смотря на то что, кажется, что они тормозят, сами макросы отрабатывают очень быстро. Тормозит компилятор немерле. Что именно там тормозит, я не знаю.
Кстати неплохо было бы сделать компилятору ключик, который в конце компиляции выводит, сколько и какая стадия заняла.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, ionoy, Вы писали:
I>>Я просто подумал, что это могло бы быть неплохой оптимизацией. Всё-таки трансляция это довольно ресурсоёмкий процесс, и если есть возможность пропускать те классы, которые уже транслированы, то пересборка будет проходить быстрее. С точки зрения разработчика это достаточно важно. WH>А ты измерял? WH>Просто чтобы посчитать хеш с учетом всех зависимостей тебе всё равно придется сделать почти всю работу. Разве что сериализацю в жабаскрипт можно не делать. А это я думаю на фоне остального копейки.
Тупо добавил DateTime в начало и конец макроса, вот результаты для разных классов: https://gist.github.com/4110555
В целом это сейчас около 1.5 секунды для проекта с сэмплами, причём больше всего времени уходит на трансляцию парсеров (что логично).
Наверное сейчас и правда нет смысла заморачиваться с оптимизациями.
WH>Например, я измерял, сколько работают мои макросы. Не смотря на то что, кажется, что они тормозят, сами макросы отрабатывают очень быстро. Тормозит компилятор немерле. Что именно там тормозит, я не знаю.
Да, у Немерле не самый шустрый компилятор.
WH>Кстати неплохо было бы сделать компилятору ключик, который в конце компиляции выводит, сколько и какая стадия заняла.
Было бы круто если этим кто-нибудь занялся. Там работа не такая уж и сложная, кропотливая разве что.
Прошу прощения что долго молчал Я вас понял, подождем менее сжатого проекта Может к тому времени выпустят РеШарпер и тогда вообще жизнь — малина станет
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, Ziaw, Вы писали:
I>>>С тонкостями MVVM не придётся разбираться, фреймворк построен так, как будто пишешь обычный шаблон. Данные сами по себе, магическим образом обновляются по мере обновления модели в коде.
Z>>Не знаю, как другие, но мне пришлось набить несколько шишек, прежде чем я въехал в саму идеологию. Принципы просты, но для их использования мне пришлось пару-тройку хороших вьюх сделать и пару раз переделать.
I>Ну да, это с любой идеологией так. Но в целом MVVM достаточно лёгок в понимании.
Здравствуйте, Ziaw, Вы писали:
Z>Я правильно понимаю, что проблема в том, чтобы натравить преттифаер после того, как код будет выведен на страницу?
Да. Есть метод
В терминах Knockout — это будет computed.
Ещё правильнее было бы сделать prettyPrint нормальной функцией, которая брала бы текст и возвращала форматированный текст.
Z>В оригинальном нокауте я бы такую проблему решил с помощью кастом биндинга.
Имхо, это как раз показатель того, насколько неудобен нокаут. Такую, казалось бы простую проблему, решать таким сложным образом.
Z>Их планируете? Без них, имхо, использовать в чем-то серьезном будет сложно. Ибо проблемы, подобные этой без них решаются только нетривиальными решениями совмещенными с правкой самого фреймворка.
Пока не планируем, зачем они нам могут понадобится? Я правда спрашиваю, может быть я просто чего-то не вижу.
Z>Кстати, а вы не думали над использованием typescript как типизатора для внешнего js? Там довольно несложный синтаксис, распарсить несложно, вот скрестить его с немерловым будет сложнее, тут я пока ничего путнего не придумал.
Надо подумать над этим. Что, например, если для той библиотеки, которая тебе нужна, ещё не существует "типизации". Писать её самому на Typescript'е?
Сейчас есть механизм JsApi, который позволяет описывать интерфейс на Немерле. Он пока в зародышном состоянии, но имхо вполне рабочее решение:
[JsApi]
public class RegExp
{
public this(_pattern : string)
{}
public compile() : void
{}
public compile(_pattern : string) : void
{}
public compile(_pattern : string, _modifier : string) : void
{}
public exec(_input : string) : array[string]
{[].ToArray()}
public test(_input : string) : bool
{false}
}
Не очень понял, как это должно работать.
I>Ещё правильнее было бы сделать prettyPrint нормальной функцией, которая брала бы текст и возвращала форматированный текст.
Может и правильнее, но разумно ли?
Z>>В оригинальном нокауте я бы такую проблему решил с помощью кастом биндинга. I>Имхо, это как раз показатель того, насколько неудобен нокаут. Такую, казалось бы простую проблему, решать таким сложным образом.
А ты попробуй сделать пару биндингов, на самом деле они просты как три копейки и вместе с ним решают все проблемы связи внешних бибилиотек не рассчитаных на подобную генерацию DOM.
I>Пока не планируем, зачем они нам могут понадобится? Я правда спрашиваю, может быть я просто чего-то не вижу.
см. выше.
Z>>Кстати, а вы не думали над использованием typescript как типизатора для внешнего js? Там довольно несложный синтаксис, распарсить несложно, вот скрестить его с немерловым будет сложнее, тут я пока ничего путнего не придумал. I>Надо подумать над этим. Что, например, если для той библиотеки, которая тебе нужна, ещё не существует "типизации". Писать её самому на Typescript'е? I>Сейчас есть механизм JsApi, который позволяет описывать интерфейс на Немерле. Он пока в зародышном состоянии, но имхо вполне рабочее решение:
Значит можно просто генерить такие классы по typescript исходникам. Оба механизма будут востребованы. У тайпскрипта явно есть будущее, так что "типизации" будут, а легкий интероп с ним будет весьма кстати.
I>>В терминах Knockout — это будет computed. Z>Не очень понял, как это должно работать.
computed инвалидируется, когда меняются данные, от которых он зависит. Сейчас, кстати, это не оптимальное решение, потому что prettyPrint раскрашивает все сорсы, до которых добирается. Из-за этого получается много ненужных вызовов.
I>>Ещё правильнее было бы сделать prettyPrint нормальной функцией, которая брала бы текст и возвращала форматированный текст. Z>Может и правильнее, но разумно ли?
Если правильно, значит и разумно
Z>>>В оригинальном нокауте я бы такую проблему решил с помощью кастом биндинга. I>>Имхо, это как раз показатель того, насколько неудобен нокаут. Такую, казалось бы простую проблему, решать таким сложным образом. Z>А ты попробуй сделать пару биндингов, на самом деле они просты как три копейки и вместе с ним решают все проблемы связи внешних бибилиотек не рассчитаных на подобную генерацию DOM.
Я писал несколько биндеров, когда делал свой сайт на нокауте. Просто не понимаю, зачем они могут нам понадобится, когда у нас не существует биндинга как отдельной сущности (во всяком случае это цель).
I>>Надо подумать над этим. Что, например, если для той библиотеки, которая тебе нужна, ещё не существует "типизации". Писать её самому на Typescript'е? I>>Сейчас есть механизм JsApi, который позволяет описывать интерфейс на Немерле. Он пока в зародышном состоянии, но имхо вполне рабочее решение: Z>Значит можно просто генерить такие классы по typescript исходникам. Оба механизма будут востребованы. У тайпскрипта явно есть будущее, так что "типизации" будут, а легкий интероп с ним будет весьма кстати.
В принципе можно написать несложный макрос, который будет парсить TypeScript и создавать JsApi класс. Только вот парсер придётся писать с нуля.
Здравствуйте, Ziaw, Вы писали:
Z>Значит можно просто генерить такие классы по typescript исходникам. Оба механизма будут востребованы. У тайпскрипта явно есть будущее, так что "типизации" будут, а легкий интероп с ним будет весьма кстати.
Насколько мне известно typescript это исключительно IDE-шная технология. Его прямая поддержка в броузерах не планируется.
Так что имеет смысл сделать генераторы немерла по typescript-у, чтобы получить возможность автоматически затягивать имеющиеся описания (если вообще это получится).
Генерация же typescript смысла не имеет. По крайней мере до тех пор пока typescript не появится в броузерах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Насколько мне известно typescript это исключительно IDE-шная технология. Его прямая поддержка в броузерах не планируется.
Ну да, это аналог jade, haml, sass, less, coffescript, etc. Технология только для разработки, в продакшен идет чистый html, css, js.
VD>Так что имеет смысл сделать генераторы немерла по typescript-у, чтобы получить возможность автоматически затягивать имеющиеся описания (если вообще это получится).
Ага, именно это я и предложил.
VD>Генерация же typescript смысла не имеет. По крайней мере до тех пор пока typescript не появится в броузерах.
А вот про генерацию я ничего не говорил. Естественно оно большого смысла не имеет, только если вдруг понадобится обратный интероп. Пока не вижу смысла даже думать об этом.
Здравствуйте, ionoy, Вы писали:
I>computed инвалидируется, когда меняются данные, от которых он зависит. Сейчас, кстати, это не оптимальное решение, потому что prettyPrint раскрашивает все сорсы, до которых добирается. Из-за этого получается много ненужных вызовов.
Все равно не понимаю. Source изменился, мы вызываем PrettifiedSource, внутри преттифаер раскрашивает всю страницу, потом мы возвращаем измененный Source и кладем его в нужный узел DOM. Когда будет раскрашен сам измененный Source? Чтобы не раскрашивать весь документ можно использовать prettyPrintOne.
I>>>Ещё правильнее было бы сделать prettyPrint нормальной функцией, которая брала бы текст и возвращала форматированный текст. Z>>Может и правильнее, но разумно ли? I>Если правильно, значит и разумно
Это правильно в данном конкретном случае. Кстати, prettyPrintOne и есть такая функция. В общем случае это решение не подходит.
I>Я писал несколько биндеров, когда делал свой сайт на нокауте. Просто не понимаю, зачем они могут нам понадобится, когда у нас не существует биндинга как отдельной сущности (во всяком случае это цель).
Я себе плохо представляю использование, например, удобного мне календаря или автокомплита без кастомных биндингов.
I>В принципе можно написать несложный макрос, который будет парсить TypeScript и создавать JsApi класс. Только вот парсер придётся писать с нуля.
Угу. Парсер у них на самом себе написан, но синтаксис очень простой, заодно получим парсер JS, ибо TS есть надмножество JS.
Здравствуйте, Ziaw, Вы писали:
I>>Только вот парсер придётся писать с нуля.
Z>Если что, положу тут ссылку на BNF грамматику EcmaScript. http://tomcopeland.blogs.com/EcmaScript.html Правда ничего не знаю насчет ее качества. Z>На первый взгляд, на пег должна переделаться один в один.
Только там грамматика не корректная будет.
Надо не забывать о Automatic Semicolon Insertion. TS этому тоже подчиняется.
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, ionoy, Вы писали:
I>>computed инвалидируется, когда меняются данные, от которых он зависит. Сейчас, кстати, это не оптимальное решение, потому что prettyPrint раскрашивает все сорсы, до которых добирается. Из-за этого получается много ненужных вызовов.
Z>Все равно не понимаю. Source изменился, мы вызываем PrettifiedSource, внутри преттифаер раскрашивает всю страницу, потом мы возвращаем измененный Source и кладем его в нужный узел DOM. Когда будет раскрашен сам измененный Source? Чтобы не раскрашивать весь документ можно использовать prettyPrintOne.
PrettifiedSource в данном случае играет роль подписчика на событие изменения Source, так как он является биндингом, зависящим от Source.
Z>Это правильно в данном конкретном случае. Кстати, prettyPrintOne и есть такая функция. В общем случае это решение не подходит.
Вот это отличная функция. Тогда можно биндить элемент страницы на функцию, которая будет возвращать раскрашенный текущий сорс.
I>>Я писал несколько биндеров, когда делал свой сайт на нокауте. Просто не понимаю, зачем они могут нам понадобится, когда у нас не существует биндинга как отдельной сущности (во всяком случае это цель). Z>Я себе плохо представляю использование, например, удобного мне календаря или автокомплита без кастомных биндингов.
Вариантов, как прибиндить календарь или автокомплит на самом деле довольно много. Надо просто отойти от идеологии нокаута и подумать, как бы ты сделал это в .NET
Самый простой:
class MainPage
{
public SelectedDate : string
{
get {
js <# $("#id").datepicker("getDate") #>
}
}
public this()
{
js <# $("#id").datepicker() #>;
}
public View()
{
<#
<div id="calendar" />
#>
}
}
Здравствуйте, fddima, Вы писали:
F> Только там грамматика не корректная будет. F> Надо не забывать о Automatic Semicolon Insertion. TS этому тоже подчиняется.
Я, кстати, тоже об этом первым делом подумал , но там куча правил заканчивается так:
( ";" )?
и я решил, что это учтено.
В том, что в этой грамматике, как почти и в любом другом нетривиальном коде есть баги — я не сомневаюсь. Вопрос в их плотности.
Здравствуйте, Ziaw, Вы писали:
Z>В том, что в этой грамматике, как почти и в любом другом нетривиальном коде есть баги — я не сомневаюсь. Вопрос в их плотности.
Ну, вопросов нет. Компактно, тем и удобно. Просто в оригинальной спецификации в приложении A тоже достаточно наглядно всё расписано.
А вот зачем Automatic Semicolon Insertion вообще выдумали — я не знаю... иногда забываю о нём и долго туплю, почему код не работает.
Здравствуйте, fddima, Вы писали:
Z>>В том, что в этой грамматике, как почти и в любом другом нетривиальном коде есть баги — я не сомневаюсь. Вопрос в их плотности. F> Ну, вопросов нет. Компактно, тем и удобно. Просто в оригинальной спецификации в приложении A тоже достаточно наглядно всё расписано. F> А вот зачем Automatic Semicolon Insertion вообще выдумали — я не знаю... иногда забываю о нём и долго туплю, почему код не работает.
Известно зачем — чтобы новички пришедшие из разных языков (BASIC ) не сильно пугались.
Здравствуйте, ionoy, Вы писали:
F>> А вот зачем Automatic Semicolon Insertion вообще выдумали — я не знаю... иногда забываю о нём и долго туплю, почему код не работает.
I>Известно зачем — чтобы новички пришедшие из разных языков (BASIC ) не сильно пугались.
Скорее всего на руби или питоне перепрограммили. Мне, после руби, бесполезная точка с запятой иногда режет глаз. Как и бесполезные круглые скобки, хотя отказ от скобок в руби — довольно дорогое удовольствие.
Automatic Semicolon Insertion в руби достаточно дешев, лишь заставляет поменять привычку писать так:
collection
.Where(x => x > 1)
.Select(x => x.ToString())
на привычку писать так:
collection.
find_all {|x| => x > 1}.
map &:to_s
что на мой испорченный взгляд выглядит по уродски. Интересно, что JS не заставляет, видимо это личные проблемы руби (и дополнительная сложность компилятора).
I>Да, выглядит странно А в Руби выражение может начинаться с точки?
По идее нет, когда-то давно мог начинаться floating literal. Начал сейчас тестировать, в 1.9.3 уже не надо такого изврата, в 1.8.7 надо. Я этого не знал, глупое поведение 1.8 заставило меня писать так всегда, хотя уже не меньше года сижу на 1.9
Здравствуйте, VladD2, Вы писали:
VD>Привет.
VD>Не хотите сварганить нам новое, крутое дерево для сайта? Такое все интерактивное и удобное...
Почему бы и нет. Только надо вместе подумать как это сделать. Для разных людей понятия удобности и интерактивности могут отличаться.
Плюс, так по мне система РСДН сама по себе неудобна, но я знаю, что многим она нравится. Так что, если есть идеи — делись.
Здравствуйте, ionoy, Вы писали:
I>Почему бы и нет. Только надо вместе подумать как это сделать. Для разных людей понятия удобности и интерактивности могут отличаться. I>Плюс, так по мне система РСДН сама по себе неудобна, но я знаю, что многим она нравится. Так что, если есть идеи — делись.
Данные для дерева пока что хранятся в ХМЛ-файле. Возможно оно так и останется.
АВК тут уже делал прототип, но времени как всегда нехватает, а делать это дело напрямую на яваскрипте очень непроизводительно.
Собственно задача описается очень просто. Надеюсь, что на NemerleWeb ее и решить можно будет относительно просто.
Требования:
Нам нужна замена для дерева используемого сейчас на сайте. Дерево должно:
1. При первоначальном открытии загружать только ветки верхнего уровня и ветки идентификаторы которых переданы в некоторую функцию навигации. Чтобы было лучше понятно о чем идет речь, открой любую статью
. Далее прокрути дерево и ты увидишь, что открыто две (или более) ветки (куда привязана статья).
2. Данные для вложенных подветок должны подгружаться по мере раскрытия веток. Иначе открытие сайта будет занимать много времени.
3. Само-собой должны быть разные анимации и другие рюшечки, чтобы народ перся .
4. У некоторых разделов (например, раздела "статьи") должен быть доступен интерфейс быстрой фильтрации содержимого. Ну, например, при чтобы при подведении мышки к заголовку раздела "статьи" над ним появлялось полупрозрачное текстовое окошко. Если в него переместиться и написать подстроку, то текущее содержимое подветки (статьи) должно пропасть, а в вместо него должно появиться дерево в котором будут только те ветки которые содержат введенную строку. Видел как это делается в Productivity Power Tools (смотри раздел "Solution Navigator").
5. Для обладателей соответствующих прав (админов сайта) должна быть доступна (например, в нижнем правом углу) специальная кнопка "Редактирование" на жав на которую чтобы можно было перейти к режиму настройки дерева. В этом режиме должны добавляться новые ветки и редактироваться имеющиеся. Как это выглядит и какие фичи там нужны я потом покажу на примере нашего текущего дамин-интерфейса.
Пятый пункт можно отложить на потом, а для начала сделать первые 4.
ХМЛ-файл с содержимым дерева я могу прислать по почте или по скайпу.
Как опция — хорошо бы сделать сменяемые "скины". Ну, чтобы можно было сменить стили и набор картинок в дереве. А то вот мне, например, иконки в дереве АВК совсем не нравятся. А ему не нравятся те что используются на сайте сейчас.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Решил попробовать Nemerle.Web для создания Single Page Application.
Nemerle установлен в каталог C:\Program Files (x86)\Nemerle\\Net-4.0\Nemerle.Compiler.dll, версия 1.1.746.0, простые примеры компилируются и запускаются нормально.
Исходники Nemerle.Web скачал из репозитория, последний коммит от 20.03.2013, комментарий "Add TSParser project to solutions".
Проблема в том, что я не могу сбилдить солюшен NemerleWeb.sln. Недостающие референсы из нугета я добавил, но после их добавления (успешного) вылезло вот такое ругательство:
Nemerle Visual Studio Integration
Error: Невозможно загрузить файл или сборку "Owin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ebd12fd5e55cc5" или один из зависимых от них компонентов. Не удается найти указанный файл.
Could not load file or assembly 'JetBrains.ReSharper.SolutionAnalysis.UI.resources, Version=7.0.1098.2760, Culture=en-US, PublicKeyToken=1010a0d8d6380325' or one of its dependencies. Не удается найти указанный файл.
Could not load file or assembly 'JetBrains.ReSharper.SolutionAnalysis.UI.resources, Version=7.0.1098.2760, Culture=en, PublicKeyToken=1010a0d8d6380325' or one of its dependencies. Не удается найти указанный файл.
Невозможно загрузить файл или сборку "Owin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ebd12fd5e55cc5" или один из зависимых от них компонентов. Не удается найти указанный файл.
Try recompile solution or referenced assembies!
При компиляции вылезает несколько тысяч ошибок, например такая:
Подскажите, как правильно сбилдить проект / что почитать по сборке проектов на Nemerle. На гитхабовской страничке проекта Nemerle.Web из всех инструкций только "скачайте исходники".
Здравствуйте, Legion13, Вы писали:
L>Решил попробовать Nemerle.Web для создания Single Page Application. L>Nemerle установлен в каталог C:\Program Files (x86)\Nemerle\\Net-4.0\Nemerle.Compiler.dll, версия 1.1.746.0, простые примеры компилируются и запускаются нормально.
На этих примерах пока и стоит экспериментировать. Я посмотрю остальные солюшены в ближайшее время.
L>
L>Nemerle Visual Studio Integration
L>Error: Невозможно загрузить файл или сборку "Owin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ebd12fd5e55cc5" или один из зависимых от них компонентов. Не удается найти указанный файл.
L>Could not load file or assembly 'JetBrains.ReSharper.SolutionAnalysis.UI.resources, Version=7.0.1098.2760, Culture=en-US, PublicKeyToken=1010a0d8d6380325' or one of its dependencies. Не удается найти указанный файл.
L>Could not load file or assembly 'JetBrains.ReSharper.SolutionAnalysis.UI.resources, Version=7.0.1098.2760, Culture=en, PublicKeyToken=1010a0d8d6380325' or one of its dependencies. Не удается найти указанный файл.
L>Невозможно загрузить файл или сборку "Owin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ebd12fd5e55cc5" или один из зависимых от них компонентов. Не удается найти указанный файл.
L>Try recompile solution or referenced assembies!
Не совсем понятно, почему он требует решарперовских сборок. Может у тебя плагин какой-то установлен?
L>Подскажите, как правильно сбилдить проект / что почитать по сборке проектов на Nemerle. На гитхабовской страничке проекта Nemerle.Web из всех инструкций только "скачайте исходники".
Ничего особенного не нужно. Скачай последний Немерле с tc.rsdn.ru, и запусти NemerleWeb.Samples.sln
L>Использую Visual Studio 2010 ver 10.0.40219.1
Надо, кстати, проверить поддержку 2010 студии, у нас все на 2012 сидят.
Здравствуйте, ionoy, Вы писали:
L>>Использую Visual Studio 2010 ver 10.0.40219.1 I>Надо, кстати, проверить поддержку 2010 студии, у нас все на 2012 сидят.
Здравствуйте, Ziaw, Вы писали:
Z>По идее нет, когда-то давно мог начинаться floating literal. Начал сейчас тестировать, в 1.9.3 уже не надо такого изврата, в 1.8.7 надо. Я этого не знал, глупое поведение 1.8 заставило меня писать так всегда, хотя уже не меньше года сижу на 1.9
А кстати правда что у руби с обратной совместимостью туго? Говорят что разница между 1.8 и 1.9 как в питоне между 2.x и 3.x? Какая у них политика в этом вопросе?
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, ionoy, Вы писали:
I>>Страница проекта: http://nemerlewebsamples.apphb.com I>>Репозиторий: https://github.com/NemerleWeb/NemerleWeb
I>>Все важные обновления будут поститься в этой теме. Здесь же можно постить свои вопросы и предложения/замечания.
A>1) Русское описание планируется или статья?
Пока нет, на все рук не хватает.
Есть ссылка на туториал на странице GitHub-а проекта: NemerleWeb Tutorial.
Можно с этого начинать.
Любая помощь приветствуется конечно
A>2) Какая цель проекта? Какие основные фичи? В общем обзорная статья не помешала бы...
Цель — писать сайты
Фичи:
1. Транслятор Nemerle -> JS
2. Связывание данных
3. Шаблоны
4. Макросы для передачи данных клиент-сервер (SignalR), для регуляции (throttling) в будущем будет для печенек (cookie)
5. Типизация JS в том числе автоматически из файлов определений TypeScript.
Здравствуйте, _NN_,
_NN>Цель — писать сайты
_NN>Фичи: _NN>1. Транслятор Nemerle -> JS _NN>2. Связывание данных _NN>3. Шаблоны _NN>4. Макросы для передачи данных клиент-сервер (SignalR), для регуляции (throttling) в будущем будет для печенек (cookie) _NN>5. Типизация JS в том числе автоматически из файлов определений TypeScript.
Насколько я понял он завязан на knockout, но там нет роутинга. Как жить дальше?
Здравствуйте, alvas, Вы писали:
A>Насколько я понял он завязан на knockout, но там нет роутинга. Как жить дальше?
У вас старая информация
Knockout-а там нет уже давно.
Сейчас связка сделана примерно как в angular-js. Никаких observable, все просто и предельно ясно.
Здравствуйте, _NN_,
_NN>Скачайте проект, поиграйтесь что ли
Уже какой раз пытаюсь, да все никак. Не могу понять возможности, а главное зачем?
А сайты писать можно и на php, ruby, python, javascript, ... Но это вы и без меня знаете
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, _NN_,
_NN>>Скачайте проект, поиграйтесь что ли
A>Уже какой раз пытаюсь, да все никак. Не могу понять возможности, а главное зачем?
Не могу понять ваш вопрос, что вы хотите узнать ?
Во первых проще, во вторых есть типизация.
Ну и наконец сайты на Nemerle, как тут не радоваться.
В дальнейшем будут еще DSL-и и будет вообще красота.
A>А сайты писать можно и на php, ruby, python, javascript, ... Но это вы и без меня знаете
На javascript ? Избавьте от такого счастья
Здравствуйте, _NN_, Вы писали:
A>>Уже какой раз пытаюсь, да все никак. Не могу понять возможности, а главное зачем? _NN>Не могу понять ваш вопрос, что вы хотите узнать ?
Может есть аналог на других языках чтобы было понятней?
_NN>Во первых проще, во вторых есть типизация.
Проще чего?
_NN>Ну и наконец сайты на Nemerle, как тут не радоваться.
Это я понял.
_NN>В дальнейшем будут еще DSL-и и будет вообще красота.
A>>А сайты писать можно и на php, ruby, python, javascript, ... Но это вы и без меня знаете _NN>На javascript ? Избавьте от такого счастья
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, _NN_, Вы писали:
A>>>Уже какой раз пытаюсь, да все никак. Не могу понять возможности, а главное зачем? _NN>>Не могу понять ваш вопрос, что вы хотите узнать ? A>Может есть аналог на других языках чтобы было понятней?
Ну например тот же http://angularjs.org/ позволяет описывать связывания через js.
_NN>>Во первых проще, во вторых есть типизация. A>Проще чего?
Проще чем простой JS.
Меньше шансов наделать ошибок.
A>Вы слышали по node.js?
И что теперь ?
Писать на JS я не собираюсь все равно.
Здравствуйте, _NN_, Вы писали:
A>>Вы слышали по node.js? _NN>И что теперь ? _NN>Писать на JS я не собираюсь все равно.
Я это к тому что на чем писать есть в избытке. Есть проблема выбора оптимального инструмента.
В автор этого фреймворка? Можно было бы обсудить цели, задачи и ближайшие планы...
Здравствуйте, ionoy, Вы писали:
I>Цель у нас амбициозная — создать лучший в мире фреймворк для разработки веб приложений
Какой у вас "Hello World"? Где у меня ошибки?
[Unit]
public class Index
{
public HelloWorld : string {
get { "Hello World!"; }
};
}
[Html]
public View() : string
{
<#
<div>
$HelloWorld
</div>
#>
}
public class Server
{
public Index() : void
{
//????
}
}
}
Только не хватало ключевым немерлистам отвлекаться на такие штуки. Есть внятный список достоинств node.js на сервере? А то все ASP.NET vs node.js что в гугле — как-то неубедительны...
Здравствуйте, alvas, Вы писали:
A>А кстати правда что у руби с обратной совместимостью туго? Говорят что разница между 1.8 и 1.9 как в питоне между 2.x и 3.x? Какая у них политика в этом вопросе?
Да вроде нет. Я не замечал особых. Вот floating literal начинающийся с точки убрали, да с кодировками наводят порядок. При переходе с 1.9 на 2.0 практически нет проблем, с 1.8 на 1.9 были небольшие проблемы с кодировками. Были еще изменения приоритетов некоторых операторов, но я всегда стараюсь ставить скобки если приоритет хоть чуть не очевиден. В целом, серьезных проблем нет. Примерно так же, как версию фреймворка поменять.
Здравствуйте, alvas, Вы писали:
A>Какой у вас "Hello World"? Где у меня ошибки?
A>
A> [Unit]
A> public class Index
A> {
A> public HelloWorld : string {
A> get { "Hello World!"; }
A> };
A> }
A> [Html]
A> public View() : string
A> {
A> <#
A> <div>
A> $HelloWorld
A> </div>
A> #>
A> }
A> public class Server
A> {
A> public Index() : void
A> {
A> //????
A> }
A> }
A> }
A>
1. В объявлении свойства на второй строчке зачем-то };
2. Класс Server нужно объявлять только тогда, когда этому юниты нужны данные с сервера — прочитать что-то из базы данных или записать обратно. При этом сериализация/десериализация происходит автоматически.
Здравствуйте, alvas, Вы писали:
A>Кстати Edge.js — Running Node.js and .NET in One Process появилась возможность к javascript прикрутить C#, F#, Python, and PowerShell и было бы здорово прикрутить N, например.
Как концепт, конечно, инетересно. Но использовать такой подход в своём коде, это имхо жесть. Я бы лучше нативными node.js либами воспользовался.
Здравствуйте, ionoy, Вы писали:
I>1. В объявлении свойства на второй строчке зачем-то }; I>2. Класс Server нужно объявлять только тогда, когда этому юниты нужны данные с сервера — прочитать что-то из базы данных или записать обратно. При этом сериализация/десериализация происходит автоматически.
Я просто качнул фреймворк, нашел пример выкинул лишнее, не понимая что делаю.
Напишите правильный
Здравствуйте, hi_octane, Вы писали:
_>Только не хватало ключевым немерлистам отвлекаться на такие штуки. Есть внятный список достоинств node.js на сервере? А то все ASP.NET vs node.js что в гугле — как-то неубедительны...
Ну может и не обязательно ключевым, но взглянуть мне кажется стоит. Кстати был сегодня на Bizspark Urkaine. Там http://skwibl.com/ рассказывали что используют node.js в продакшене и "всем довольны"
M$ Azure поддерживает node.js, например... Чем нода лучше ASP.NET не знаю , но может как раз за счет N это преимущество и появится
Здравствуйте, alvas, Вы писали:
A>Кстати Edge.js — Running Node.js and .NET in One Process появилась возможность к javascript прикрутить C#, F#, Python, and PowerShell и было бы здорово прикрутить N, например. A>Влад! Ты где?
По поводу прикручивания чего-то к чему-то — это не ко мне. У нас и так времени катастрофически не хватает.
Могу только помочь консультациями по разным тонким вопросам связанным с немерлом. А уж прикручивать вы как-нибудь сами пробуйте.
Кроме того не вижу смысла в данной затее. Немерл на сервере и так самодостаточен. Заменять его скриптами или смесью скриптов статики неразумно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
I> [Unit]
I> public class Index
I> {
I> public HelloWorld : string {
I> get { "Hello World!"; }
I> }
I> [Html]
I> public View() : string
I> {
I> <#
I> <div>
I> $HelloWorld
I> </div>
I> #>
I> }
I> }
I>
I>Только там зайди в HomeController, проверь, что возвращается именно Index
Cпасибо
1) Как еще можно передавать данные во вьюху, кроме как через свойства?
2) Можно передавать dynamic? Кстати его(dynamic) поддерживает текущая версия N?
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, _NN_, Вы писали:
A>>>Вы слышали по node.js? _NN>>И что теперь ? _NN>>Писать на JS я не собираюсь все равно.
A>Я это к тому что на чем писать есть в избытке. Есть проблема выбора оптимального инструмента. A>В автор этого фреймворка? Можно было бы обсудить цели, задачи и ближайшие планы...
С удовольствием.
Мы будем только рады.
В планах довести дело до ума, обкатывая на дереве для RSDN.
Починить компилятор , чтобы была нормальная версионость
.
Соответственно компилятор выложить в виде NuGet пакета.
И сам NemerleWeb выложить в виде NuGet пакета.
При этом добавить шаблоны для студии, чтобы были заготовки в один клик.
P.S.
Если вы желаете принять участие в разработке, имеет смысл перейти на более скорый способ общения в виде чата.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alvas, Вы писали:
A>>P.S. Меня смущает что N пропал из под Linux...
VD>Дык вместо того чтобы смущаться лучше было бы помочь исправить это досадное недоразумение.
VD>В прочем, в прошлый раз проблемы были в Моно. А народ не стал терпеть не компилируемые пакеты.
Я просто купил Rapsberry Pi. Не нарадуюсь с него и Линукса
Как говорил один лектор про Windows. Это конечно все прекрасно, но это в Линуксе было еще надцать лет назад
Возьмем например Nuget. Ну вы поняли.
P.S. Кто не понял — такая вича есть уже давно в python — pip, в ruby — gem, в linux — apt-get.....
Здравствуйте, _NN_, Вы писали:
NN>P.S. _NN>Если вы желаете принять участие в разработке, имеет смысл перейти на более скорый способ общения в виде чата.
Здравствуйте, alvas, Вы писали:
A>Кстати Edge.js — Running Node.js and .NET in One Process появилась возможность к javascript прикрутить C#, F#, Python, and PowerShell и было бы здорово прикрутить N, например. A>Влад! Ты где?
Так вся фишка Nemerle в высокоуровневости языка.
Зачем опускаться на более низкий уровень, если можно выразить все проще через макросы и DSL.
А из этого сгенерировать , например, тот же C# или JS.
Хардкейс работает над заморозкой версий.
_NN>Соответственно компилятор выложить в виде NuGet пакета.
Это невозможно. NuGet может только сборки распростронять. А для немерла нужна установка в конкретны каталог. Да еще и регистрация интеграции.
_NN>И сам NemerleWeb выложить в виде NuGet пакета. _NN>При этом добавить шаблоны для студии, чтобы были заготовки в один клик.
Хорошая идея.
Nemerle.dll мы в NuGet добавим, скорее всего. Вот с самим немерлом большой вопрос. Его NuGet-ом скорее всего ставить не выйдет. Вот как расширение для студии — можно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _NN_, Вы писали:
_NN>Так вся фишка Nemerle в высокоуровневости языка. _NN>Зачем опускаться на более низкий уровень, если можно выразить все проще через макросы и DSL. _NN>А из этого сгенерировать , например, тот же C# или JS.
Это да, но приведите пример сайта на N, кроме вашего дерева для rsdn?
В единстве сила (с) Конь Юлий из "Алеша Попович и Тугарин Змей"
Здравствуйте, alvas, Вы писали:
A>Cпасибо A>1) Как еще можно передавать данные во вьюху, кроме как через свойства?
Можно и простые поля
Можно любые методы вызывать.
Может я не понял ваш вопрос ?
A>2) Можно передавать dynamic? Кстати его(dynamic) поддерживает текущая версия N? A>
Увы нет
Есть макрос late, который почти dynamic, но не совсем то. http://nemerle.org/Late_Binding_Macro
Было бы конечно хорошо иметь dynamic, но еще никто не приделал.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alvas, Вы писали:
A>>2) Можно передавать dynamic?
VD>А, зачем?
Ruby + Python + .Net 4.0 на этот вопрос ответили утвердительно. Так есть или нет? Планируется или нет?
A>>Кстати его(dynamic) поддерживает текущая версия N?
VD>Он пока что никому был не нужен. Когда нужна динамика обычно применяют макрос late. Он не уступает dynamic из C#, но обычно его за глаза хватает.
Понял. Перечитаю первоисточник, чтобы освежить в памяти
VD>Немерл интересен своей строгой статической типизацией. Так что dynamic в нем просто не нужен.
.
VD>Хардкейс работает над заморозкой версий.
Очень интересно.
Будет примерно так как описано в предложении ?
_NN>>Соответственно компилятор выложить в виде NuGet пакета.
VD>Это невозможно. NuGet может только сборки распростронять. А для немерла нужна установка в конкретны каталог. Да еще и регистрация интеграции.
Не совсем.
Скажем для AppHarbor достаточно положить все в один каталог и он сам запускает компилятор.
Очень удобно.
Поэтому не стоит отказываться от такой поддержки.
_NN>>И сам NemerleWeb выложить в виде NuGet пакета. _NN>>При этом добавить шаблоны для студии, чтобы были заготовки в один клик.
VD>Хорошая идея.
VD>Nemerle.dll мы в NuGet добавим, скорее всего. Вот с самим немерлом большой вопрос. Его NuGet-ом скорее всего ставить не выйдет. Вот как расширение для студии — можно.
Ну ставить не надо, только возможность компиляции.
См. выше.
P.S. Я надеюсь что ты меня за это не убьешь, но Хейлсберг оказался не таким тупым, как ты его считаешь.
Хоть он и не ввел до сих пор в c# мощную систему макросов — привет Roslyn — на зато имеем Linq и dynamic
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, _NN_, Вы писали:
_NN>>Так вся фишка Nemerle в высокоуровневости языка. _NN>>Зачем опускаться на более низкий уровень, если можно выразить все проще через макросы и DSL. _NN>>А из этого сгенерировать , например, тот же C# или JS.
A>Это да, но приведите пример сайта на N, кроме вашего дерева для rsdn?
У нас их аж 2
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, _NN_, Вы писали:
NN>>P.S. _NN>>Если вы желаете принять участие в разработке, имеет смысл перейти на более скорый способ общения в виде чата.
A>Когда и где?
Скайп подойдет ? Мой юзер там nn552870. все никак не могу сменить
Здравствуйте, _NN_, Вы писали:
VD>>Хардкейс работает над заморозкой версий. _NN>Очень интересно. _NN>Будет примерно так как описано в предложении ?
Примерно так.
_NN>Не совсем. _NN>Скажем для AppHarbor достаточно положить все в один каталог и он сам запускает компилятор. _NN>Очень удобно. _NN>Поэтому не стоит отказываться от такой поддержки.
Вы можете попробовать, конечно. Но почти уверен, что у вас ничего хорошего не выйдет.
_NN>Ну ставить не надо, только возможность компиляции.
Дык, а откуда она появится? Кроме того не нужно забывать про интеграцию. Ее референсом не поставить. Это плагин к студии. А без нее довольно бессмысленно говорить о нагете вообще. Он же только в рамках проекта студийного имеет смысл.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alvas, Вы писали:
A>1) Как еще можно передавать данные во вьюху, кроме как через свойства?
Всё, что возвращает значение можно запихнуть во вьюху.
$(Prop), $(_field), $(MethodCall()), $("string"), $(if(true) "true" else "false") ну и так далее.
И это будет биндинг, а не просто одноразовая передача данных.
Здравствуйте, alvas, Вы писали:
A>Хоть он и не ввел до сих пор в c# мощную систему макросов — привет Roslyn — на зато имеем Linq и dynamic
Тут все очень просто. Если в каком-то языке появляется что-то стоящее, то мы оцениваем это и заимствуем, если оно того стоит. Linq мы позаимствовали, dynamic — нет, потому что от него нет никакого толку для нас.
Если кто-то с нами не согласен, то он может сам воспроизвести нужную ему фичу в виде макроса.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _NN_, Вы писали:
_NN>Может я не понял ваш вопрос ?
Вы все правильно поняли
A>>2) Можно передавать dynamic? Кстати его(dynamic) поддерживает текущая версия N? A>> _NN>Увы нет _NN>Есть макрос late, который почти dynamic, но не совсем то. _NN>http://nemerle.org/Late_Binding_Macro
Вспомнил. Нужно просто обновить знание
_NN>Было бы конечно хорошо иметь dynamic, но еще никто не приделал.
_NN>Тут тоже неясно, что вы хотите сделать.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, alvas, Вы писали:
A>>Здравствуйте, _NN_, Вы писали:
_NN>>>Так вся фишка Nemerle в высокоуровневости языка. _NN>>>Зачем опускаться на более низкий уровень, если можно выразить все проще через макросы и DSL. _NN>>>А из этого сгенерировать , например, тот же C# или JS.
A>>Это да, но приведите пример сайта на N, кроме вашего дерева для rsdn? _NN>У нас их аж 2
_NN>Даже есть Nemerle.Peg в JS. _NN>NemerleWeb Samples _NN>NemerleWeb Tests
Это да. А зачем вы тайпскрипт прикручиваете? Шучу-шучу
_NN>Сами понимаете. Будет больше желающих помочь, будет и больше сайтов.
Я за, но вы сначала определитесь зачем нужен ваш фреймворк и какие задачи он решает Я серьезно
A>>В единстве сила (с) Конь Юлий из "Алеша Попович и Тугарин Змей"
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, alvas, Вы писали:
A>>Здравствуйте, _NN_, Вы писали:
NN>>>P.S. _NN>>>Если вы желаете принять участие в разработке, имеет смысл перейти на более скорый способ общения в виде чата.
A>>Когда и где?
_NN>Скайп подойдет ? Мой юзер там nn552870. все никак не могу сменить
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alvas, Вы писали:
A>>Хоть он и не ввел до сих пор в c# мощную систему макросов — привет Roslyn — на зато имеем Linq и dynamic
VD>Тут все очень просто. Если в каком-то языке появляется что-то стоящее, то мы оцениваем это и заимствуем, если оно того стоит. Linq мы позаимствовали, dynamic — нет, потому что от него нет никакого толку для нас.
VD>Если кто-то с нами не согласен, то он может сам воспроизвести нужную ему фичу в виде макроса.
Это да. Я про то что он делает с c# правильные вещи, хоть и не в том порядке
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, _NN_, Вы писали:
_NN>>>Починить компилятор , чтобы была нормальная версионость
.
VD>>Хардкейс работает над заморозкой версий.
A>Кстати nemelish почил в бозе или живее всех живых?
Он собирается, надо его вернуть в инсталлятор.
Уровень конечно не такой как другие REPL.
Для простых случае проще взять NPad
A>P.S. REPL позволяет брать любой язык с низкого старта
Здравствуйте, _NN_, Вы писали:
A>>Кстати nemelish почил в бозе или живее всех живых? _NN>Он собирается, надо его вернуть в инсталлятор. _NN>Уровень конечно не такой как другие REPL. _NN>Для простых случае проще взять NPad
Здравствуйте, VladD2, Вы писали:
A>>P.S. REPL позволяет брать любой язык с низкого старта
VD>Это явное преувеличение. Можно с тем же успехом играться с языком в IDE. Там и сервисов по больше. И интерактивность вполне приемлемая.
А теперь представь что у меня нет гуи? Линух или веб?
I>$(Prop), $(_field), $(MethodCall()), $("string"), $(if(true) "true" else "false") ну и так далее.
I>И это будет биндинг, а не просто одноразовая передача данных.
Расшифруйте пожалуйста "бывшему депутату Государственной думы"
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alvas, Вы писали:
A>>А теперь представь что у меня нет гуи? Линух или веб?
VD>Веб то где? Разве что опять в Линуксе. Не уже ли ни одной машины с виндой? В прочем тогда можно виртуальку поставить.
Я понимаю что уже поздно и все сонные. Но html он и виндовсе html
Здравствуйте, VladD2, Вы писали:
VD>Если кто-то с нами не согласен, то он может сам воспроизвести нужную ему фичу в виде макроса.
Проблема с dynamic не в том, что не хватает функциональности, а в сложности общения со сторонними либами, которые этот dynamic используют.
Здравствуйте, alvas, Вы писали:
I>>$(Prop), $(_field), $(MethodCall()), $("string"), $(if(true) "true" else "false") ну и так далее. I>>И это будет биндинг, а не просто одноразовая передача данных.
A>Расшифруйте пожалуйста "бывшему депутату Государственной думы"
Первое или второе?
<div>$Prop</div> - в этом диве будет всегда отображаться актуальное значение свойства Prop
<div>$_field</div> - то же самое, но значение поля
<div>$(MethodCall())</div> - здесь будет результат вызова функции, тоже всегда актуальный
<div>$("string")</div> - это просто пример того, что биндить можно к любому значению, даже если это просто неизменяемая строка
<div>$(if(true) "true" else "false")</div> - биндинг может содержать выражения возвращающие значение, коим является if/else
более реалистичный пример if/else:
<div>$(if(LoggedIn) "Hello, " + Name else "Please, log in")</div>
Если, например, поле Name изменилось, то автоматически будут обновлены все места использования этого Name. Никаких действий со стороны программиста для этого не нужно.
Здравствуйте, alvas, Вы писали:
A>Это да. А зачем вы тайпскрипт прикручиваете? Шучу-шучу
TypeScript сейчас нужен для того, чтобы не писать вручную обёртки над яваскрипт либами. Очень удобно.
_NN>>Сами понимаете. Будет больше желающих помочь, будет и больше сайтов. A>Я за, но вы сначала определитесь зачем нужен ваш фреймворк и какие задачи он решает Я серьезно
Так мы уже с самого начала определились.
1. Фреймворк нужен для упрощения написания браузерных приложений
2. Фреймворк — это яваскрипт транслятор + биндинг наподобие AngularJS + шаблоны. А так, как всё это ещё и находится под крылом Немерле, то выходит очень мощная штука, благодаря возможности использовать макросы для устранения boilerplate кода.
Ещё раз хочу подчеркнуть, мы не заменяем ASP.NET MVC, Nancy или другие серверные технологии, мы работаем поверх них. То есть сайт на ASP.NET MVC так и останется сайтом на ASP.NET MVC. Но на тех страницах, где нужна интерактивность очень удобно использовать NemerleWeb.
Всё, что изменится — это вместо того, чтобы в экшене контроллера написать:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _NN_, Вы писали:
_NN>>Он собирается, надо его вернуть в инсталлятор.
VD>Собирается и работает — разные вещи. Никуда возвращать его не надо. Он полностью неработоспособен.
Попробовал NPad. Не консольный и не под Линукс, но тоже классный
Здравствуйте, alvas, Вы писали:
A>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, _NN_, Вы писали:
_NN>>>Он собирается, надо еговернуть в инсталлятор.
VD>>Собирается и работает — разные вещи. Никуда возвращать его не надо. Он полностью неработоспособен.
A>Попробовал NPad. Не консольный и не под Линукс, но тоже классный
Почему не под линукс?
Винформы там работают хорошо, это ведь не wpf.
Здравствуйте, _FRED_, Вы писали:
_FR>Что за парадокс? Что-то ничего невыгуглилось
Обычно это называют парадоксом дней рождений. При чём тут шапки я не знаю.
Делай что должно, и будь что будет
Re[9]: Общая информация по NemerleWeb
От:
Аноним
Дата:
11.06.13 16:41
Оценка:
Здравствуйте, SergH, Вы писали:
SH>Здравствуйте, _FRED_, Вы писали:
_FR>>Что за парадокс? Что-то ничего невыгуглилось
SH>Обычно это называют парадоксом дней рождений. При чём тут шапки я не знаю.
Пришло 20 человек и побросали шапки в кучу. Когда уходили никто не помнил где, чья шапка и по этому взяли случайно.
Какова вероятность что хотя бы один взял свою шапку.
Здравствуйте, ionoy, Вы писали:
I>Про MainPage.Instance.IsActiveNode(c) я не совсем понял наезда. Да, можно было бы в каждую ноду передавать экземпляр MainPage, чтобы она могла вызывать IsActiveNode. Я выбрал sinlgeton, потому что немного выгоднее по перформансу, так как MainPage не надо передавать в отдельном цикле.
Как минимум обращение к MainPage.Instance.IsActiveNode нужно было поместить в свойство модели представления. Ну, а лучше чтобы MainPage.Instance все же передавалось при создании. Возможно завести модельку TreeView в которой хранить все данные для дерева.
I>Насчёт отдельной компиляции, то тут тоже всё не так просто. Если у кого есть интерес, то можно будет обсудить.
Думаю, что отдельная компиляция вьюшек расположенных в отдельных файлах была бы кстати. Но пока на нее можно забить. Добавите в следующей версии. Возможно уже на базе N2.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
I>Здесь же можно постить свои вопросы и предложения/замечания.
Не выходит собрать решение.
------ Перестроение всех файлов начато: проект: NemerleWeb.TypedJS, Конфигурация: Debug Any CPU ------
All packages listed in packages.config are already installed.
D:\Projects\NemerleWeb\NemerleWeb.TypedJS\JSStringExtensions.n(14,45): error : unbound type name `RegExp'
D:\Projects\NemerleWeb\NemerleWeb.TypedJS\Properties\NWebProperties.n(3,12): error : the custom attribute `GenerateTypedJS(Root = "NemerleWeb.TypedJS", Lib = "lib.d.ts", Files = [("Scripts", "typings\\\\(underscore\\\\(underscore|underscore-typed-.*)|linq\\\\linq)\\.d\\.ts")])' could not be found or is invalid
confused by earlier errors bailing out
Построение проекта "NemerleWeb.TypedJS.nproj" завершено с ошибкой.
Здравствуйте, STDray, Вы писали:
_NN>>Для начала версия Nemerle самая свежая ? _NN>>http://www.nemerle.org/Downloads
STD>Сначала была какая-то древняя. Я обновил до 1.2.0.40, но ошибка сохранилась.
А можно весь лог получить ?
Желательно сначала очистить всю папку от лишней грязи (git clean)
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, STDray, Вы писали:
_NN>>>Для начала версия Nemerle самая свежая ? _NN>>>http://www.nemerle.org/Downloads
STD>>Сначала была какая-то древняя. Я обновил до 1.2.0.40, но ошибка сохранилась.
_NN>А можно весь лог получить ? _NN>Желательно сначала очистить всю папку от лишней грязи (git clean)
Можно, но уже не нужно. У меня какая-то шляпа с папкой проекта произошла. Забрал последнюю версию в новую директорию и все собралось. Спасибо за помощь.
Здравствуйте, STDray, Вы писали:
STD>Можно, но уже не нужно. У меня какая-то шляпа с папкой проекта произошла. Забрал последнюю версию в новую директорию и все собралось. Спасибо за помощь.
Кстати если хотите попробовать шаблоны для NemerleWeb.
Нужно запустить спец команду на сайте внизу: www.nemerleweb.com/
Тогда можно будет легко создавать новые проекты на NemerleWeb
_NN>Кстати если хотите попробовать шаблоны для NemerleWeb. _NN>Нужно запустить спец команду на сайте внизу: www.nemerleweb.com/ _NN>Тогда можно будет легко создавать новые проекты на NemerleWeb
Я попробую. Но на данный момент, мне надо было протестировать какой-то уже готовый проект. Я начитался какой-то темы, что верстальщики страдают от студии, компиляций и релоадов, потому написал конпелирующий веб-сервер. А сэмплы немемрлевеб собираться отказались, потом оказалось, что и студия их собрать не может. Но сейчас все нормально.
Здравствуйте, _NN_, Вы писали:
_NN>Кстати если хотите попробовать шаблоны для NemerleWeb. _NN>Нужно запустить спец команду на сайте внизу: www.nemerleweb.com/ _NN>Тогда можно будет легко создавать новые проекты на NemerleWeb
А почему у вас на сайте http://www.nemerleweb.com/ работает только ссылка на сайт Немерле, а кнопки — нет?
Здравствуйте, Legion13, Вы писали:
L>Здравствуйте, _NN_, Вы писали:
_NN>>Кстати если хотите попробовать шаблоны для NemerleWeb. _NN>>Нужно запустить спец команду на сайте внизу: www.nemerleweb.com/ _NN>>Тогда можно будет легко создавать новые проекты на NemerleWeb
L>А почему у вас на сайте http://www.nemerleweb.com/ работает только ссылка на сайт Немерле, а кнопки — нет?
Потому что сайт в процессе разработки, у ionoy еще не было времени доделать, а я занять поддержкой TypeScript 0.9 .
Кстати, код сайта открыт если желаете помочь