NN's Blog
Мой первый блог на RSDN :)
Общая информация по NemerleWeb
24.08.2012
|
ionoy |
Страница проекта: http://nemerlewebsamples.apphb.com
Репозиторий: https://github.com/NemerleWeb/NemerleWeb
Все важные обновления будут поститься в этой теме. Здесь же можно постить свои вопросы и предложения/замечания.
Репозиторий: https://github.com/NemerleWeb/NemerleWeb
Все важные обновления будут поститься в этой теме. Здесь же можно постить свои вопросы и предложения/замечания.
24.08.2012 306 комментариев |
Lists and collections глючит. Попробуй добавить/удалить несколько раз.
WH>Lists and collections глючит. Попробуй добавить/удалить несколько раз.
Интересная проблема, странно, что о ней нет ничего на сайте KnockoutJs.
Дело в том, что Seats.Remove конвертируется в вызов метода destroy (observableArray), который в свою очередь выставляет у объекта свойство _destroy = true.
Объекты, у которых _destroy == true, игнорируются при биндингах, как будто их нет. Но, загвоздка в том, что свойство length, после destroy() не изменяется. А специального метода length(), который бы учитывал _destroy у observableArray тоже нет.
Очень странная недоработка. Видимо придётся пока вообще отказаться от destroy в пользу remove.
В данном примере используется comp list, но если автор Nemerle.ComputationExpressions согласится помочь, то можно будет прикрутить и comp async.
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 загружен по самые не могу.
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 и засовывало "продолжение" в этот параметр. Как это сделать, я, если честно, не разобрался.
I>В данном примере используется comp list, но если автор Nemerle.ComputationExpressions согласится помочь, то можно будет прикрутить и comp async.
Для асинка теперь есть отдельная реализация. Вроде как более удобная.
VD>Для асинка теперь есть отдельная реализация. Вроде как более удобная.
Если это аналог C# async, то там всё переписывается в TPL. А мне такая тяжёлая артиллерия не нужна, достаточно просто подставить коллбек куда нужно.
I>Страница проекта: http://user1663.netfx45lab.discountasp.net/
I>Репозиторий: https://github.com/ionoy/NemerleWeb
I>Все важные обновления будут поститься в этой теме. Здесь же можно постить свои вопросы и предложения/замечания.
было бы позитивно написать краткую инструкцию для начала использования:
как то ставим то и то, создаем каталог х, копируем туда пример из y, запускаем на компиляцию или еще что и пр.
есть мнение, что не все знают ASP net и прочую лабуду, и как ее активировать в связке с NemerleWeb.
это помогло бы не только тем, что вообще не в теме web и asp но и тем, кто имеет дело с альтернативными технологиями.
_C_>было бы позитивно написать краткую инструкцию для начала использования:
_C_>как то ставим то и то, создаем каталог х, копируем туда пример из y, запускаем на компиляцию или еще что и пр.
_C_>есть мнение, что не все знают ASP net и прочую лабуду, и как ее активировать в связке с NemerleWeb.
_C_>это помогло бы не только тем, что вообще не в теме web и asp но и тем, кто имеет дело с альтернативными технологиями.
Это всё будет как только мы будем уверены, что фреймворк готов для обычного пользователя. На данный момент там ещё слишком много недоработок и досадных багов.
Если интересно просто "поиграться", то делай клон с гитхаба и работай в проекте MVCTest. Никакой особенной магии там не нужно.
От разработчика не требуется ни строчки кода конфигурации. Просто пишешь:
и он вызывается на клиенте. Вся обвязка автоматически генерируется макросом, и только в том случае, если где то есть вызов клиентского метода.
На http://user1663.netfx45lab.discountasp.net/ появился пример Chat using SignalR, где можно посмотреть на это вживую, а так же увидеть код.
Немере умеет выводить типы в инициалайзерах. Так что можно писать так
I>На http://user1663.netfx45lab.discountasp.net/ появился пример Chat using SignalR, где можно посмотреть на это вживую, а так же увидеть код.
Похоже он не работает.
I>Страница проекта: http://user1663.netfx45lab.discountasp.net/
А варианты и сопоставление с образцом работает? Если да, то хорошо бы сделать примерчик по этому поводу.
VD>А варианты и сопоставление с образцом работает? Если да, то хорошо бы сделать примерчик по этому поводу.
Варианты пока не работают. Надо прикинуть, какой ЖС для них генерировать и вообще какая функциональность обычных классов перейдёт и к ним.
Паттерн матчинг должен работать в полную силу, кроме, конечно, сопоставления вариантов.
I>Варианты пока не работают. Надо прикинуть, какой ЖС для них генерировать и вообще какая функциональность обычных классов перейдёт и к ним.
Надо.
I>Паттерн матчинг должен работать в полную силу, кроме, конечно, сопоставления вариантов.
Ну, дык варианты в ПМ самое вкусное. Надо сделать.
I>Хотелось бы услышать от сообщества предложения по поводу работы с БД. Моё главное пожелание, это возможность в простых случаях не писать ни строчки "мета" кода. То есть весь код работы с базой это db.Add и подобное, а генерацией базы и прочим должен заниматься фреймворк. И отталкиваясь от этого пошаговая расширяемость.
Генерировать сторепроц?
I>Хотелось бы услышать от сообщества предложения по поводу работы с БД. Моё главное пожелание, это возможность в простых случаях не писать ни строчки "мета" кода. То есть весь код работы с базой это db.Add и подобное, а генерацией базы и прочим должен заниматься фреймворк. И отталкиваясь от этого пошаговая расширяемость.
А чем использование линка не устраивает?
VD>А чем использование линка не устраивает?
Вполне устраивает. Меня больше интересуют инфраструктурные вопросы, как генерировать базу и прочее.
Может у кого-то возникнет интересная идея.
I>Вполне устраивает. Меня больше интересуют инфраструктурные вопросы, как генерировать базу и прочее.
I>Может у кого-то возникнет интересная идея.
У Ziaw есть движок миграций. Можно для начала его приспособить. Но лично я бы предпочел подход от модели (что МС называют код-фирст), когда описывается модель в виде некоторого ДСЛ-я и уже по ней генерируется БД и миграции.
VD>У Ziaw есть движок миграций. Можно для начала его приспособить. Но лично я бы предпочел подход от модели (что МС называют код-фирст), когда описывается модель в виде некоторого ДСЛ-я и уже по ней генерируется БД и миграции.
Главное, что мне нравилось в nHibernate, это как раз-таки автоматическая генерация и обновление базы по модели. Наверное, что-то вроде этого и надо будет прикрутить, например взять из EF. Если кто знает где ещё это реализовано, предлагайте.
I>Главное, что мне нравилось в nHibernate, это как раз-таки автоматическая генерация и обновление базы по модели. Наверное, что-то вроде этого и надо будет прикрутить, например взять из EF. Если кто знает где ещё это реализовано, предлагайте.
EF сюда тащить — это перебор.
Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД.
Вообщем — это большая отдельная задача и я бы посоветовал не смешивать их.
Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД.
VD>Лучше сколотить команду которой интересен весь этот энтерпрайз и доделав твой движок взяться за поддержку БД.
А еще лучше скооперироваться с IT'ом. И сделать крутой BLT для немерла.
VD>Подход "от модели" мне тоже больше нравится. Но у него есть один минус. Тяжело организовать эволюционный процесс развития имеющихся БД.
Почему тяжело? Обновлять базу данных "вперёд" как раз легко. Насчёт отката не уверен, никогда не приходилось.
I>Здравствуйте, VladD2, Вы писали:
VD>>А чем использование линка не устраивает?
I>Вполне устраивает. Меня больше интересуют инфраструктурные вопросы, как генерировать базу и прочее.
I>Может у кого-то возникнет интересная идея.
Позволю процитировать один свой мысль по этому поводу
и здесь реализация реализация этого для случая встроенной бд.
ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора
_C_>ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора
Поднял тему — развивай
_NN>Здравствуйте, _Claus_, Вы писали:
_C_>>ЗЫ. Рекламирую принцип, а не свою реализацию, ибо она нуждается в расширении возможностей компилятора
_NN>Поднял тему — развивай
вам хочется песен — их есть у меня!
уже это показывал здесь — реакции не было. вообще. подожду думаю лет пять. обычно потом принимают как родное.
что непонятно или расшифровать — спрашивайте.
для тех, кому лень читать что попало — основная мысль:
макротипы — это штука, которая стирает (прячет) грань между простым кодом и макросом.
работая с макротипом(и), как с обычным классом, мы в итоге получаем любой согласованный везде код, количество и сложность которого ограничена только нашей фантазией.
имея макротипы для бд или гуя мы перекомпилировав с одним другим юсингом получим высокооптимальный код для заказанной платформы.
со всеми связками, хмлями и прочей лабудой, нужной для платформозависимого кода, и о которой разумному программисту и знать не надо.
I>Хотелось бы услышать от сообщества предложения по поводу работы с БД. Моё главное пожелание, это возможность в простых случаях не писать ни строчки "мета" кода. То есть весь код работы с базой это db.Add и подобное, а генерацией базы и прочим должен заниматься фреймворк. И отталкиваясь от этого пошаговая расширяемость.
db.Users.Insert(() => new User { Name = "Новый юзер" });
Это C# + BLToolkit
J>db.Users.Insert(() => new User { Name = "Новый юзер" });
J>Это C# + BLToolkit
Да, про BLT знаю и, кстати, предполагал именно его использовать для доступа. Вопрос тут скорее для того, что может быть кто-то придумает нечто полезное и интересное с использованием макросов.
I>Да, про BLT знаю и, кстати, предполагал именно его использовать для доступа.
C blt, кстати, та же проблема, что и с nemerle.dll, зависимость от конкретной версии. Если Nemerle.Web еще можно включить в инсталятор nemerle и она всегда будет ссылаться на доступную версию nemerle.dll, то ее зависимость от конкретного тулкита будет уже довольно печальным фактом.
Z>C blt, кстати, та же проблема, что и с nemerle.dll, зависимость от конкретной версии. Если Nemerle.Web еще можно включить в инсталятор nemerle и она всегда будет ссылаться на доступную версию nemerle.dll, то ее зависимость от конкретного тулкита будет уже довольно печальным фактом.
Есть какие-то идеи как это решить?
I>Есть какие-то идеи как это решить?
Компилять все с исходников!
VD>Компилять все с исходников!
Это мысль. Надо выяснить, умеет ли nuget делать пакеты из проектов с исходным кодом. Потому, что подключать проект с исходниками руками удовольствие ниже среднего.
J>db.Users.Insert(() => new User { Name = "Новый юзер" });
J>Это C# + BLToolkit
Уж на Немерле можно было бы и более приличный синтаксис сделать. Insert/Update/Delete в стиле SQL были бы очень приятной фичей.
VD>Уж на Немерле можно было бы и более приличный синтаксис сделать. Insert/Update/Delete в стиле SQL были бы очень приятной фичей.
Это наверное вопрос предпочтений, но я тот же линк с SQL синтаксисом использую только в особо запутаных случаях.
А подобную фичу кто-нибудь мог бы реализовать отдельным макросом, не зависящим от фреймворка или чего-то ещё.
Просто должны быть подстановки по договорённости select -> Select(), и возможность их оверрайдить через макросы уровня сборки.
Итак благодаря компиляции C# файлов можно использовать даже C# для ViewModel.
На данный момент Nemerle требуется только для самого метода View.
Код и рабочий пример можно увидеть на тестовом сайте: http://user1663.netfx45lab.discountasp.net/
Variants and Pattern Matching
Не работает. Цвет не выставляется.
WH>Variants and Pattern Matching
WH>Не работает. Цвет не выставляется.
Там сейчас баг в IE и некоторых других браузерах, попозже исправим.
Попробуй Chrome, FF или IE10, там должно работать.
I>Там сейчас баг в IE и некоторых других браузерах, попозже исправим.
I>Попробуй Chrome, FF или IE10, там должно работать.
FF 15 цвет выбрать можно. Квадратик всегда белый.
IE 9 цвет выбрать нельзя (в комбобоксе пусто). Квадратик красный.
Других браузеров нет и ставить лень.
Зато в процессе его изучения я нашёл, что биндинг там реализован очень просто. Тупо проходимся по всем элементам, к которым прибинжены значения, создаём для них листенеры, и потом просто на каждый чих проверяем изменилось ли значение, и если да, то обновляем элемент. Там есть две основных функции $apply и $digest.
Псевдокод:
Так как большинство изменений происходит внутри самих биндингов, то их запросто можно обернуть в $apply. Если значение изменяется извне (таких сценариев очень, очень мало), то $digest надо вызывать вручную.
Вот я и прикинул, что проще написать подобную либу самому, заодно избавится от любых ограничений, которые накладывались сторонними либами. Так что теперь NemerleWeb работает на нашей либе nweb.js, её можно найти в NemerleWeb.Samples/Scripts/nweb.js. Потом она переедет в более удобное место.
I>Вот я и прикинул, что проще написать подобную либу самому, заодно избавится от любых ограничений, которые накладывались сторонними либами. Так что теперь NemerleWeb работает на нашей либе nweb.js, её можно найти в NemerleWeb.Samples/Scripts/nweb.js. Потом она переедет в более удобное место.
good!
I>Зато в процессе его изучения я нашёл, что биндинг там реализован очень просто. Тупо проходимся по всем элементам, к которым прибинжены значения, создаём для них листенеры, и потом просто на каждый чих проверяем изменилось ли значение, и если да, то обновляем элемент. Там есть две основных функции $apply и $digest.
Мне кажется более правильным путь — это расчет зависимостей статически во время компиляции. Все что для этого нужно сделать:
1. Выудить информацию о зависимостях из кода.
2. Построить граф (DAG) зависимостей.
3. Произвести топологическую сортировку.
4. Сгенерить по отсортированному графу код модифицирующих зависимости.
Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
Вот код топологической сортировки который я недавно написал для собственных нужд:
VD>Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
Этот вариант просто переносит генерацию биндингов с клиента на сервер. Больше, он практически ничем не отличается, в обоих случаях нам надо анализировать DOM. А при изменении значения как ни крути придётся все биндинги проверять, тут никакие макросы не помогут. Точнее, если запретить модификацию моделей извне, то в принципе можно анализировать код модели и искать места, где происходят изменения. Но если честно, то выхлопа от подобной оптимизации будет немного, а работы, причём нетривиальной там дофига.
Ребята из AngularJS говорят, что пробежка по биндингам и так достаточно шустрая, вполне сносно работает даже на страницах с сотнями связей.
Ну и самое главное, это сейчас совсем не в приоритете. Проблему "специфичного кода" мы решили, теперь биндить можно произвольный javascript, а дальше есть и другие интересные задачи.
VD>>Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
I>Этот вариант просто переносит генерацию биндингов с клиента на сервер. Больше, он практически ничем не отличается,
Он дает статический контроль. Эдак можно говорить о том, что и вся твоя библиотека ничего недает, так как все тоже самое можно на клиентском джава-скрипте залудить.
VD>Здравствуйте, ionoy, Вы писали:
VD>>>Преимущества данного подхода — во время компиляции можно будет выявлять зацикливания и другие ошибки в биндинге. Ну, и код можно более эффективный сгенерировать, так как он будет для конкретных случаев генерироваться, а не всегда бегать по всему ДОМ-у.
I>>Этот вариант просто переносит генерацию биндингов с клиента на сервер. Больше, он практически ничем не отличается,
VD>Он дает статический контроль. Эдак можно говорить о том, что и вся твоя библиотека ничего недает, так как все тоже самое можно на клиентском джава-скрипте залудить.
Влад, мне не понятна твоя любовь к статистической проверки и не любовь к доказательному программированию...
А>Влад, мне не понятна твоя любовь к статистической проверки и не любовь к доказательному программированию...
Откуда ты взял про нелюбовь? Я не люблю лишнего кода и лишних усилий. Если найдут пути доказательства корректности без дополнительных аннотация, я с удовольствием поддержку это начинание. Но глядя на примеры на современных языках вроде Агдя мне становится грустно.
Статическая же типизация не привнося оверхэда (его нивелирует вывод типов) дает вполне себе ощутимые бенефиты. То кто развивал сложный проект это отлично знает. Рефакторинг без статической типизация — это лотерея, а не программирование.
К тому же мне кажется более перспективной идея повышения надежности за счет поднятия уровня языка (ДСЛ-и и т.п.). В нем мы так же получаем возможность доказывать корректность своих программ, но при этом не увеличиваем объем программ, а наоборот сокращаем его.
VD>Он дает статический контроль. Эдак можно говорить о том, что и вся твоя библиотека ничего недает, так как все тоже самое можно на клиентском джава-скрипте залудить.
Статический контроль даёт, да. Но что мы сможем проверить? Большая часть кода и DOM'а уже проверена на сервере, библиотека для биндинга это как накладка сверху, она собственно ничего нового в код не приносит.
Лучше уже тогда в самом трансляторе или Html макросе корректность проверять. К этому, кстати, всё и идёт, но явно не прямо сейчас, потому как это задача непростая, а из бенефитов только warning в окне output. Повторюсь, сейчас работы и без того хватает.
I>Статический контроль даёт, да. Но что мы сможем проверить?
Все. В итоге у вас должно получиться полностью статическое решение, которое проверяет все составляющие во время компиляции. Именно в этом его ценность, так как динамических аналогов выше крыши.
И кидать надо не ворнинги, а сообщения об ошибках.
Плюс зная связях статически можно генерировать более быстрый и надежный код.
VD>Все. В итоге у вас должно получиться полностью статическое решение, которое проверяет все составляющие во время компиляции. Именно в этом его ценность, так как динамических аналогов выше крыши.
Так у нас компилятор и так уже почти всё проверяет. Приведи пример хоть?
Я пока только циклические зависимости увидел, но если честно я даже не знаю, стоит ли такое пытаться отлавливать. Никто же в С#/Nemerle компиляторе этим не занимается, чем наш транслятор отличается?
I>Страница проекта: http://user1663.netfx45lab.discountasp.net/
Не работает.
А>Не работает.
Демо переехало сюда: http://moiety.apphb.com/
_NN>Здравствуйте, Аноним, Вы писали:
А>>Не работает.
_NN>Демо переехало сюда: http://moiety.apphb.com/
А чат где?
А>Здравствуйте, _NN_, Вы писали:
_NN>>Здравствуйте, Аноним, Вы писали:
А>>>Не работает.
_NN>>Демо переехало сюда: http://moiety.apphb.com/
А>А чат где?
Вам интересен фреймворк или хотите потрепаться ?
Чат восстановлен.
А>>Не работает.
_NN>Демо переехало сюда: http://moiety.apphb.com/
Я же просил сказать мне новый адрес. Сейчас поправлю в теме.
I>Страница проекта: http://moiety.apphb.com
Откровенно говоря эти цветочки на фоне как-то не в кассу. Может заменить их на что-то более приличное?
VD>Откровенно говоря эти цветочки на фоне как-то не в кассу. Может заменить их на что-то более приличное?
А че, веселенько так, жизнерадостно.
VD>Откровенно говоря эти цветочки на фоне как-то не в кассу. Может заменить их на что-то более приличное?
Как придёт вдохновение, так и поправим Сменой дизайна в плановом порядке заниматься не хочется.
I>Страница проекта: http://moiety.apphb.com
В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.
VD>Здравствуйте, ionoy, Вы писали:
I>>Страница проекта: http://moiety.apphb.com
VD>В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.
Не совсем понял проблему.
И браузер какой ?
VD>>В тесте "Loading and saving", после удаления одной из строки во всплывающем окне (при записи) всегда пишется 0 уделенных строк.
_NN>Не совсем понял проблему.
_NN>И браузер какой ?
Зайди в этот тест, нажми "Delete" и нажми "Save". Далее внимательно изучи результат.
Помнится ionoy там что-то химичил, но результат получился некрасивым. Надо бы поправить.
VD>Зайди в этот тест, нажми "Delete" и нажми "Save". Далее внимательно изучи результат.
VD>Помнится ionoy там что-то химичил, но результат получился некрасивым. Надо бы поправить.
Сейчас работает? У меня вроде как всё нормально.
I>Здравствуйте, VladD2, Вы писали:
VD>>Зайди в этот тест, нажми "Delete" и нажми "Save". Далее внимательно изучи результат.
VD>>Помнится ionoy там что-то химичил, но результат получился некрасивым. Надо бы поправить.
I>Сейчас работает? У меня вроде как всё нормально.
Глючит.
Удалить.
Сохранить.
Удалить.
при том 2 будут указаны как удаленные.
Удаленне записи после сохранения не удаляются.
А>Глючит.
А>Удалить.
А>Сохранить.
А>Удалить.
А>при том 2 будут указаны как удаленные.
А>Удаленне записи после сохранения не удаляются.
В рамках примера это ожидаемое поведение. Таски просто помечаются как удалённые, но на самом деле не удаляются. По идее сервер должен их "удалять" из базы данных и отвечать, что они реально удалены. Тогда их можно вычистить из списка.
В принципе можно пример доделать в этом плане, просто никто не заморачивался.
I>Сейчас работает? У меня вроде как всё нормально.
Ага. Заработало.
Не корректно рпботает пример с цветным прямоугольником, при выборе цвета Ред поля ввода не скрываются
А>Здравствуйте, ionoy, Вы писали:
А>Не корректно рпботает пример с цветным прямоугольником, при выборе цвета Ред поля ввода не скрываются
Сейчас постоянно меняется код транслятора и сопутствующего окружения, поэтому следить за тем, чтобы все сэмплы работали не всегда получается.
Будет время, глянем.
I>Страница проекта: http://nemerlewebsamples.apphb.com
I>Репозиторий: https://github.com/ionoy/NemerleWeb
I>Все важные обновления будут поститься в этой теме. Здесь же можно постить свои вопросы и предложения/замечания.
Есть ли поддежка CommonJS и AMD модулей ?
Есть ли способ использования js-библиотек, опять же ввиде CommonJS и AMD ?
I>Есть ли поддежка CommonJS и AMD модулей ?
Нет. Если есть конкретные предложения, как эту поддержку добавить, то вполне вероятно, что сделаем.
I>Есть ли способ использования js-библиотек, опять же ввиде CommonJS и AMD ?
Пока что только в виде:
В принципе можно добавить javascript парсер, который будет автоматически добавлять обёртки для API сторонних библиотек, но пока за это не брались.
Сейчас доделываем поддержку PEG, это должно быть достаточно круто.
Невероятными усилиями удалось транслировать PEG.
Исходный код был немного переделан в связи с некоторыми ограничениями NemerleWeb.
По мере их устранения, код вернется в прежний вид.
Смотреть тут раздел "Calculator" : http://nemerlewebsamples.apphb.com/
Кому интересно подключайтесь
Выражаю благодарность ionoy
_NN>Смотреть тут раздел "Calculator" : http://nemerlewebsamples.apphb.com/
Маньяки Вы бы сделали изменение урла при кликах на сэмплы — удобнее давать ссылки.
_NN>Невероятными усилиями удалось транслировать PEG.
Можно глупый вопрос? А нафига? Я конечно понимаю, что парсеры на js теперь писать легко и приятно, а что парсить-то будем?
Z>Можно глупый вопрос? А нафига? Я конечно понимаю, что парсеры на js теперь писать легко и приятно, а что парсить-то будем?
Первоначально нужен был парсер Markdown, прикинули, что было бы круто для этого прикрутить PEG. В процессе исправили много недоработок, и сделали транслятор более универсальным.
Для чего реально может ещё понадобится пока неизвестно, но осознание наличия такого мощного инструмента очень даже радует.
Z>Здравствуйте, _NN_, Вы писали:
_NN>>Невероятными усилиями удалось транслировать PEG.
Z>Можно глупый вопрос? А нафига? Я конечно понимаю, что парсеры на js теперь писать легко и приятно, а что парсить-то будем?
К примеру можно парсить BBCode сайта RSDN и выдавать предварительный просмотр без сервера
Добавилась поддержка ref/out, в связи с чем макрос PEG практически не пришлось менять.
Парсер JSON полностью работает.
Частично работает парсер JavaScript.
Как только все пройдет успешно, попробуем парсер C#
Смотреть тут
Как обычно выражаю благодарность ionoy
Вам еще вот что нужно сделать:
Сейчас вы генерируете код прямо в страницу. Это плохо. Ибо страница раздувается до безобразия.
ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого.
Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится.
Таким образом, можно будет значительно сократить трафик при небольших изменениях в больших приложениях.
WH>Вам еще вот что нужно сделать:
WH>Сейчас вы генерируете код прямо в страницу. Это плохо. Ибо страница раздувается до безобразия.
WH>ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого.
WH>Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится.
WH>Таким образом, можно будет значительно сократить трафик при небольших изменениях в больших приложениях.
Да, мы об этом уже думали. Там вместе с этим надо будет некоторые инфраструктурные изменения сделать, поэтому пока откладывали.
Сваливать всё в один запрос конечно никуда не годится
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.
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.
Надо будет поправить, спс.
I>Это дело надо серъёзно обдумать, если есть желание помочь, то было бы неплохо. Можно в скайпе конфу создать и обсудить всё.
I>Нам двоим сейчас и так забот хватает — NN пилит PEG, я в этом время исправляю/дополняю транслятор. После этого можно будет подумать над правильной организацией скриптов.
Что тут думать, не надо переизобретать то, что уже есть, работает и все этим пользуются.
I>Ну так оно так и работает. Достаточно добавить класс с атрибутом Unit и вернуть его из какого-нибудь экшена.
отлично
Z>>Убежден, что технология выстрелит только при использовании оригинального knockoutjs (либо будучи 100% совместимой с ним). Я понимаю причины которые побудили создать свой велосипед. Но для популярности нужен либо http://knockoutjs.com/ и поддержка MS либо 100% совместимость с ним (и в будущем тоже). Насколько сложно сейчас вернуться на knockoutjs, пусть даже с использованием манкипатчинга?
I>А смысл? Никто всё равно не видит, что там под капотом творится, а Нокаут сильно ограничивает нас в трансляции. С новым биндингом у нас практически неограниченные возможности, а раньше постоянно приходилось бороться с Нокаутом, причём частенько безуспешно.
А над капотом? Биндинги те же? Принципы observable, computed? Возможность создания собственных биндингов? Насколько сложно сделать что-то не очень стандартное, типа свойства которое биндится на класс элемента, не трогая классы уже прописанные в разметке, биндинг даты на календарь? Где про все это прочитать? 95% потенциальных пользователей пробовали нокаут и знают как с ним работать, хорошо бы их не переобучать. Я пока не на 100% в этом уверен, но надо хорошо подумать над этим вопросом. Сейчас нокаут идет в шаблоне MVC проекта и людей, которые его знают становится все больше.
Z>Здравствуйте, ionoy, Вы писали:
I>>Это дело надо серъёзно обдумать, если есть желание помочь, то было бы неплохо. Можно в скайпе конфу создать и обсудить всё.
Z>Что тут думать, не надо переизобретать то, что уже есть, работает и все этим пользуются.
Надо решить, как будут формироваться скрипты. Сохранять ли их физически на диск? (Нужно разрешение на запись, что не всегда есть) Прописывать скрипт в поле и возвращать его потом из экшена?
Может быть стоит добавить ключ в конфигурацию?
Z>А над капотом? Биндинги те же? Принципы observable, computed? Возможность создания собственных биндингов? Насколько сложно сделать что-то не очень стандартное, типа свойства которое биндится на класс элемента, не трогая классы уже прописанные в разметке, биндинг даты на календарь? Где про все это прочитать? 95% потенциальных пользователей пробовали нокаут и знают как с ним работать, хорошо бы их не переобучать. Я пока не на 100% в этом уверен, но надо хорошо подумать над этим вопросом. Сейчас нокаут идет в шаблоне MVC проекта и людей, которые его знают становится все больше.
Никаких observable или computed тут нет, это всё осталось в нокауте. Теперь у нас есть произвольный объект, например:
Можно биндиться ко всему, что возвращает значение, будь то функция или поле.
При этом биндинг в HTML выглядит не так как в нокауте, а просто
<span class="greeting" class="$SomeClass">This is greeting: $(User.greeting)</span>
На данный момент, чтобы добавить класс к уже прописанным статически придётся добавлять второй атрибут class, но это просто потому что никто этим не занимался. Там немного парсер надо поправить и всё будет работать.
WH>ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого.
WH>Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится.
Круто! А что делать если хэши совпадут? Они ведь по определению не уникальны.
VD>Круто! А что делать если хэши совпадут? Они ведь по определению не уникальны.
SHA1 совпадет? А ты знаешь, что GIT использует SHA1 в качестве первичного ключа?
Что будет, если у двух исходных файлов SHA1 совпадет? Это же репозиторий GIT'а сломается...
Короче на данный момент не известно ни одной коллизии SHA1.
WH>SHA1 совпадет?
Хэш есть хэш. Вероятность может и низка, но она 100% есть.
WH>А ты знаешь, что GIT использует SHA1 в качестве первичного ключа?
Я в детали не вдавался. Если это так и никаких дополнительных действий не предпринимается, то вероятность дублирования есть. Возможно они тупо добавляют время комита, что делает вероятность совпадения совсем мизерной.
WH>Что будет, если у двух исходных файлов SHA1 совпадет? Это же репозиторий GIT'а сломается...
WH>Короче на данный момент не известно ни одной коллизии SHA1.
А их кто-то проверяет?
В общем, хэш есть хэш. Уникальным его можно считать разве что условно. А изменение файла можно отслеживать и по времени или сочетании хэша и времени.
VD>Хэш есть хэш. Вероятность может и низка, но она 100% есть.
Спасибо кэп.
VD>Я в детали не вдавался. Если это так и никаких дополнительных действий не предпринимается, то вероятность дублирования есть. Возможно они тупо добавляют время комита, что делает вероятность совпадения совсем мизерной.
Ничего они дополнительно не делают.
И HG тоже живет на SHA1. И тоже ничего дополнительно не делает.
VD>А их кто-то проверяет?
Проверяют. Еще как проверяют. Толпы криптографов только этим и занимаются.
VD>В общем, хэш есть хэш. Уникальным его можно считать разве что условно. А изменение файла можно отслеживать и по времени или сочетании хэша и времени.
Время не нужно.
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 На правах шутки
A>Здравствуйте, VladD2, Вы писали:
A>PS Я нигде не ошибся?
A>PPS На правах шутки
Ошибся, при вычислениях коллизий хеша берут корень из числа значений т.е примерно 10^24 (парадокс шапок)
Хеш относильно легко подделывается, а генерация пар текстов имеющих один и тот же хеш плевое дело давно уже....
но если злой умысел можно исключить, то винт сгорит всяко быстрее даи сервер сменят...
А>Здравствуйте, artelk, Вы писали:
A>>PS Я нигде не ошибся?
A>>PPS На правах шутки
А>Ошибся, при вычислениях коллизий хеша берут корень из числа значений т.е примерно 10^24 (парадокс шапок)
А>Хеш относильно легко подделывается, а генерация пар текстов имеющих один и тот же хеш плевое дело давно уже....
Но это другая задача, она проще, чем подобрать другой текст с тем же хэшем.
А>но если злой умысел можно исключить, то винт сгорит всяко быстрее даи сервер сменят...
Был один js, его как-то поменяли (без намерения сделать так, чтобы результат имел тот же хэш). Какова вероятность?
А>Хеш относильно легко подделывается, а генерация пар текстов имеющих один и тот же хеш плевое дело давно уже....
Для SHA1? Ссылку на работу можно?
А>Ошибся, при вычислениях коллизий хеша берут корень из числа значений т.е примерно 10^24 (парадокс шапок)
Что за парадокс? Что-то ничего невыгуглилось
WH>>SHA1 совпадет?
VD>Хэш есть хэш. Вероятность может и низка, но она 100% есть.
WH>>А ты знаешь, что GIT использует SHA1 в качестве первичного ключа?
VD>Я в детали не вдавался. Если это так и никаких дополнительных действий не предпринимается, то вероятность дублирования есть. Возможно они тупо добавляют время комита, что делает вероятность совпадения совсем мизерной.
Да она и так, мягко говоря, настолько около нуля, что добавление времени ничего здесь не изменит.
VD>>Круто! А что делать если хэши совпадут? Они ведь по определению не уникальны.
WH>SHA1 совпадет? А ты знаешь, что GIT использует SHA1 в качестве первичного ключа?
WH>Что будет, если у двух исходных файлов SHA1 совпадет? Это же репозиторий GIT'а сломается...
WH>Короче на данный момент не известно ни одной коллизии SHA1.
Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано.
I>Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано.
тогда название и хеш
I>>Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано.
А>тогда название и хеш
Это настоящее вредительство и хэппи дебаг, при разработке.
Как только сервер сгенерирует новый хеш, все наши брейкпойнты уедут в небытие. Собственно моим сообщением ниже именно эта проблема и решается.
I>Вообще у нас упор на читаемость, поэтому хотелось бы и имена файлов в виде названий классов с неймспейсом. В таком случае легко дебужиться в браузере, не знаю, правда насколько это будет востребовано.
Думаю востребовано.
1. Можно в конец JS файла добавлять такой комментарий:
(Возможно надо его оградить переносами строк, был какой-то нюанс не помню уже). Это должно заставить дебаггер отображать этот ресурс именно с этим именем. Chrome и FF это должны поддерживать. Сам я давно этим уже не пользовался, но раньше точно работало.
2. Сейчас вроде как модно Source Maps — механизм посложнее, но и возможностей поболее. Использовать пока не довелось, не разбирался. Chrome DevTools его поддерживает (нужно включить в настройках devtools).
F>1. Можно в конец JS файла добавлять такой комментарий:
F>
F>(Возможно надо его оградить переносами строк, был какой-то нюанс не помню уже). Это должно заставить дебаггер отображать этот ресурс именно с этим именем. Chrome и FF это должны поддерживать. Сам я давно этим уже не пользовался, но раньше точно работало.
Не знал, спасибо! Если это работает во ФФ и Хроме, то будет очень даже неплохо.
WH>Вам еще вот что нужно сделать:
WH>Сейчас вы генерируете код прямо в страницу. Это плохо. Ибо страница раздувается до безобразия.
WH>ИМХО будет лучше генерировать код для каждого класса в отдельный js файл. При этом имя этому файлу давать на основе SHA1 от его содержимого.
WH>Тогда таким файлам можно будет выставлять вечное кеширование. Ибо если файл изменится, то и его имя изменится.
WH>Таким образом, можно будет значительно сократить трафик при небольших изменениях в больших приложениях.
В общем думаем в ближайшее время заняться этой проблемой.
Надо определится, на основе чего считать хеш:
1. Некое сериализированное представление класса (все члены + PExpr методов в виде строки)
2. Исходные файлы. Тут непонятно, как их правильно доставать. В TypeBuilder они вроде как есть, но пути там указаны относительные, то есть нужно найти корневой каталог.
Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку?
I>Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку?
У вас уже всё есть.
Вы генерируете коде на жабаскрипте.
Это и есть полное представление всех значимых деталей класса, текущей версии немерла и всех макросов.
Если что-то изменится, то изменится и код. А значит и хэш.
А если код не изменится, то можно будет и старый использовать. Ибо он идентичен.
Что нам и нужно.
I>>Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку?
WH>У вас уже всё есть.
Короче просто нужно считать хеш от содержимого генерируемого файла.
I>>Я пока склоняюсь к первому варианту, он имхо наиболее логичный. Вопрос такой: как лучше всего сложить всю информацию о типе в одну строку?
WH>У вас уже всё есть.
WH>Вы генерируете коде на жабаскрипте.
WH>Это и есть полное представление всех значимых деталей класса, текущей версии немерла и всех макросов.
WH>Если что-то изменится, то изменится и код. А значит и хэш.
WH>А если код не изменится, то можно будет и старый использовать. Ибо он идентичен.
WH>Что нам и нужно.
Я просто подумал, что это могло бы быть неплохой оптимизацией. Всё-таки трансляция это довольно ресурсоёмкий процесс, и если есть возможность пропускать те классы, которые уже транслированы, то пересборка будет проходить быстрее. С точки зрения разработчика это достаточно важно.
I>Я просто подумал, что это могло бы быть неплохой оптимизацией. Всё-таки трансляция это довольно ресурсоёмкий процесс, и если есть возможность пропускать те классы, которые уже транслированы, то пересборка будет проходить быстрее. С точки зрения разработчика это достаточно важно.
А ты измерял?
Просто чтобы посчитать хеш с учетом всех зависимостей тебе всё равно придется сделать почти всю работу. Разве что сериализацю в жабаскрипт можно не делать. А это я думаю на фоне остального копейки.
Например, я измерял, сколько работают мои макросы. Не смотря на то что, кажется, что они тормозят, сами макросы отрабатывают очень быстро. Тормозит компилятор немерле. Что именно там тормозит, я не знаю.
Кстати неплохо было бы сделать компилятору ключик, который в конце компиляции выводит, сколько и какая стадия заняла.
WH>Здравствуйте, ionoy, Вы писали:
I>>Я просто подумал, что это могло бы быть неплохой оптимизацией. Всё-таки трансляция это довольно ресурсоёмкий процесс, и если есть возможность пропускать те классы, которые уже транслированы, то пересборка будет проходить быстрее. С точки зрения разработчика это достаточно важно.
WH>А ты измерял?
WH>Просто чтобы посчитать хеш с учетом всех зависимостей тебе всё равно придется сделать почти всю работу. Разве что сериализацю в жабаскрипт можно не делать. А это я думаю на фоне остального копейки.
Тупо добавил DateTime в начало и конец макроса, вот результаты для разных классов: https://gist.github.com/4110555
В целом это сейчас около 1.5 секунды для проекта с сэмплами, причём больше всего времени уходит на трансляцию парсеров (что логично).
Наверное сейчас и правда нет смысла заморачиваться с оптимизациями.
WH>Например, я измерял, сколько работают мои макросы. Не смотря на то что, кажется, что они тормозят, сами макросы отрабатывают очень быстро. Тормозит компилятор немерле. Что именно там тормозит, я не знаю.
Да, у Немерле не самый шустрый компилятор.
WH>Кстати неплохо было бы сделать компилятору ключик, который в конце компиляции выводит, сколько и какая стадия заняла.
Было бы круто если этим кто-нибудь занялся. Там работа не такая уж и сложная, кропотливая разве что.
Ещё вопрос. Как мне из макроса узнать, где находится корневая папка проекта во время компиляции? Файлы то нужно куда-то сохранять.
I>Ещё вопрос. Как мне из макроса узнать, где находится корневая папка проекта во время компиляции? Файлы то нужно куда-то сохранять.
Manager.Option ... если не ошибаюсь. В общем, в опциях командной строки.
VD>Manager.Option ... если не ошибаюсь. В общем, в опциях командной строки.
Ага, нашли уже. Спасибо.
примеры не выделяются цветом
А>Здравствуйте, ionoy, Вы писали:
А>примеры не выделяются цветом
Проблема известная.
Будем решать.
_NN>Проблема известная.
_NN>Будем решать.
Я правильно понимаю, что проблема в том, чтобы натравить преттифаер после того, как код будет выведен на страницу? В оригинальном нокауте я бы такую проблему решил с помощью кастом биндинга. Их планируете? Без них, имхо, использовать в чем-то серьезном будет сложно. Ибо проблемы, подобные этой без них решаются только нетривиальными решениями совмещенными с правкой самого фреймворка.
Кстати, а вы не думали над использованием typescript как типизатора для внешнего js? Там довольно несложный синтаксис, распарсить несложно, вот скрестить его с немерловым будет сложнее, тут я пока ничего путнего не придумал.
Z>Я правильно понимаю, что проблема в том, чтобы натравить преттифаер после того, как код будет выведен на страницу?
Да. Есть метод
Нужно вызвать prettyPrint после его выполнения.
Мне кажется, самым правильным решением будет биндить на функцию:
В терминах Knockout — это будет computed.
Ещё правильнее было бы сделать prettyPrint нормальной функцией, которая брала бы текст и возвращала форматированный текст.
Z>В оригинальном нокауте я бы такую проблему решил с помощью кастом биндинга.
Имхо, это как раз показатель того, насколько неудобен нокаут. Такую, казалось бы простую проблему, решать таким сложным образом.
Z>Их планируете? Без них, имхо, использовать в чем-то серьезном будет сложно. Ибо проблемы, подобные этой без них решаются только нетривиальными решениями совмещенными с правкой самого фреймворка.
Пока не планируем, зачем они нам могут понадобится? Я правда спрашиваю, может быть я просто чего-то не вижу.
Z>Кстати, а вы не думали над использованием typescript как типизатора для внешнего js? Там довольно несложный синтаксис, распарсить несложно, вот скрестить его с немерловым будет сложнее, тут я пока ничего путнего не придумал.
Надо подумать над этим. Что, например, если для той библиотеки, которая тебе нужна, ещё не существует "типизации". Писать её самому на Typescript'е?
Сейчас есть механизм JsApi, который позволяет описывать интерфейс на Немерле. Он пока в зародышном состоянии, но имхо вполне рабочее решение:
I>Мне кажется, самым правильным решением будет биндить на функцию:
I>
I>В терминах Knockout — это будет computed.
Не очень понял, как это должно работать.
I>Ещё правильнее было бы сделать prettyPrint нормальной функцией, которая брала бы текст и возвращала форматированный текст.
Может и правильнее, но разумно ли?
Z>>В оригинальном нокауте я бы такую проблему решил с помощью кастом биндинга.
I>Имхо, это как раз показатель того, насколько неудобен нокаут. Такую, казалось бы простую проблему, решать таким сложным образом.
А ты попробуй сделать пару биндингов, на самом деле они просты как три копейки и вместе с ним решают все проблемы связи внешних бибилиотек не рассчитаных на подобную генерацию DOM.
I>Пока не планируем, зачем они нам могут понадобится? Я правда спрашиваю, может быть я просто чего-то не вижу.
см. выше.
Z>>Кстати, а вы не думали над использованием typescript как типизатора для внешнего js? Там довольно несложный синтаксис, распарсить несложно, вот скрестить его с немерловым будет сложнее, тут я пока ничего путнего не придумал.
I>Надо подумать над этим. Что, например, если для той библиотеки, которая тебе нужна, ещё не существует "типизации". Писать её самому на Typescript'е?
I>Сейчас есть механизм JsApi, который позволяет описывать интерфейс на Немерле. Он пока в зародышном состоянии, но имхо вполне рабочее решение:
Значит можно просто генерить такие классы по typescript исходникам. Оба механизма будут востребованы. У тайпскрипта явно есть будущее, так что "типизации" будут, а легкий интероп с ним будет весьма кстати.
Слабо знаком с Веб девелопментом, но что понял при первом знакомстве — я бы убил создателей Javascript
Все-таки я приверженец статической типизации.
Есть насущный вопрос. Сумбурно но, надеюсь, главная идея будет понятна.
Надо делать программу под мобильные девайсы, очень неплохо подходит PhoneGap, так как переносима между платформами да и слишком больших наворотов в графике не предвидется. В голове витают такие мысли: есть ли возможность вашим фреймворком сделать скрипты, страницы так чтобы я их смог спокойно запихнуть в PhoneGap и наслаждаться девелопментом в Nemerle?
D>Здравствуйте, ionoy, Вы писали:
D>Слабо знаком с Веб девелопментом, но что понял при первом знакомстве — я бы убил создателей Javascript
D>Все-таки я приверженец статической типизации.
Яваскрипт на самом деле очень интересный язык и для многих вещей очень удобен. Просто Немерле круче
D>Есть насущный вопрос. Сумбурно но, надеюсь, главная идея будет понятна.
D>Надо делать программу под мобильные девайсы, очень неплохо подходит PhoneGap, так как переносима между платформами да и слишком больших наворотов в графике не предвидется. В голове витают такие мысли: есть ли возможность вашим фреймворком сделать скрипты, страницы так чтобы я их смог спокойно запихнуть в PhoneGap и наслаждаться девелопментом в Nemerle?
Теоретически это вполне реально. Я правда не пробовал на PhoneGap что-то делать, надо будет посмотреть. Но так как транслятор сейчас универсальный, то не составит труда генерировать какой угодно код.
Сейчас мы постоянно меняем что-то в фреймворке, поэтому нельзя закладываться на какую-либо функциональность. Ну и самое главное, кто-то должен реализовать ту часть, которая будет отвечать за PhoneGap. Если есть желание, то мы поможем всем чем сможем Прикручивать можно и сейчас начать, для этого необязательно ждать пока мы всё исправим.
D>>Здравствуйте, ionoy, Вы писали:
D>>Слабо знаком с Веб девелопментом, но что понял при первом знакомстве — я бы убил создателей Javascript
D>>Все-таки я приверженец статической типизации.
I>Яваскрипт на самом деле очень интересный язык и для многих вещей очень удобен. Просто Немерле круче
Да некоторые вещи интересны но, честно, извините, не люблю языков поощряющих прострел ноги Хочу чтобы ошибки искал компилятор, а не юзверь.
I>Сейчас мы постоянно меняем что-то в фреймворке, поэтому нельзя закладываться на какую-либо функциональность. Ну и самое главное, кто-то должен реализовать ту часть, которая будет отвечать за PhoneGap. Если есть желание, то мы поможем всем чем сможем Прикручивать можно и сейчас начать, для этого необязательно ждать пока мы всё исправим.
Похоже нужно реализовывать интерфейс к Cordova. Пока еще в этом дуб дубом, любая помощь приветствуется. Если тыкните пальцем куда копать — нароем.
https://github.com/phonegap/phonegap
D>Похоже нужно реализовывать интерфейс к Cordova. Пока еще в этом дуб дубом, любая помощь приветствуется. Если тыкните пальцем куда копать — нароем.
D>https://github.com/phonegap/phonegap
Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
I>Здравствуйте, Danchik, Вы писали:
D>>Похоже нужно реализовывать интерфейс к Cordova. Пока еще в этом дуб дубом, любая помощь приветствуется. Если тыкните пальцем куда копать — нароем.
D>>https://github.com/phonegap/phonegap
I>Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
Если я не ошибаюсь так оно и есть (бегло глянув на содержимое).
Значит, заюзав произвольную Style Library можна начать ваять сайт с использованием вашего фрамеворка?
I>>Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
D>Если я не ошибаюсь так оно и есть (бегло глянув на содержимое).
D>Значит, заюзав произвольную Style Library можна начать ваять сайт с использованием вашего фрамеворка?
В принципе да, только надо будет для начала добавить возможность генерировать файлы на жёсткий диск. Плюс нужен какой-то механизм для Master Pages.
Первое я собирался делать сразу после того, как полностью допилим PEG (что должно произойти на днях).
Ну и ещё не совсем продумали, как и куда правильней сохранять полученный код, а главное, как его потом отдавать. Хотелось бы разобраться с этим вопросом раз и на всегда, чтобы потом не вносить ломающих изменений в такую важную часть фреймворка.
I>Здравствуйте, Danchik, Вы писали:
I>>>Я так понимаю, PhoneGap это просто набор интерфейсов (Cordova). Девелопер создаёт произвольную HTML страницу, и там этими интерфейсами пользуется, так?
D>>Если я не ошибаюсь так оно и есть (бегло глянув на содержимое).
D>>Значит, заюзав произвольную Style Library можна начать ваять сайт с использованием вашего фрамеворка?
I>В принципе да, только надо будет для начала добавить возможность генерировать файлы на жёсткий диск. Плюс нужен какой-то механизм для Master Pages.
I>Первое я собирался делать сразу после того, как полностью допилим PEG (что должно произойти на днях).
Ну что ж, для меня это будет просто киллер фича
I>Ну и ещё не совсем продумали, как и куда правильней сохранять полученный код, а главное, как его потом отдавать. Хотелось бы разобраться с этим вопросом раз и на всегда, чтобы потом не вносить ломающих изменений в такую важную часть фреймворка.
Надеюсь это случится в этом году )))
Теперь вопрос, есть ли какой-то механизм задания типизированного интерфейса к жаваскрипту? Например с Cordova. Имееется ввиду что-то подобное:
I>Страница проекта: http://nemerlewebsamples.apphb.com
I>Репозиторий: https://github.com/NemerleWeb/NemerleWeb
I>Все важные обновления будут поститься в этой теме. Здесь же можно постить свои вопросы и предложения/замечания.
Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн). Есть за плечами опыт в одном сайте всего лишь и охота, наконец, заюзать Немерл, поскольку толкусь на этом форуме уже год, почитываю, облизываюсь, а заюзать не особо есть где. Вопрос: если я воспользуюсь текущими наработками по NemerleWeb, это не сильно ударит по яйкам? В какой стадии проект?
M>Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн). Есть за плечами опыт в одном сайте всего лишь и охота, наконец, заюзать Немерл, поскольку толкусь на этом форуме уже год, почитываю, облизываюсь, а заюзать не особо есть где. Вопрос: если я воспользуюсь текущими наработками по NemerleWeb, это не сильно ударит по яйкам? В какой стадии проект?
Сэмплы работают, тесты проходят.
Пока не все, но это скоро поправим.
Баги описаны тут.
Вы озвучьте требования, а там будет видно подойдет или нет.
К тому же тут надо учитывать, что возможно придется править или улучшать саму библиотеку.
Про компилятор я скромно промолчу
_NN>Здравствуйте, Mumusan, Вы писали:
M>>Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн). Есть за плечами опыт в одном сайте всего лишь и охота, наконец, заюзать Немерл, поскольку толкусь на этом форуме уже год, почитываю, облизываюсь, а заюзать не особо есть где. Вопрос: если я воспользуюсь текущими наработками по NemerleWeb, это не сильно ударит по яйкам? В какой стадии проект?
_NN>Сэмплы работают, тесты проходят.
_NN>Пока не все, но это скоро поправим.
_NN>Баги описаны тут.
_NN>Вы озвучьте требования, а там будет видно подойдет или нет.
_NN>К тому же тут надо учитывать, что возможно придется править или улучшать саму библиотеку.
_NN>Про компилятор я скромно промолчу
не работаеют пегпримеры
А>не работаеют пегпримеры
Калькулятор работает.
Скоро и остальное работать будет
M>Я тут собираюсь для себя, но в довольно короткие сроки сайт сделать (есть дедлайн).
Если сроки короткие и область вебразработки не очень знакома, я крайне не рекомендую добавлять еще две области с которыми не приходилось сталкивать серьезно (Nemerle и Nemerle.Web). Вам придется разобраться с особенностями языка, особенностями MVVM. То, что напрямую с яваскриптом работать не придется не означает, что без его знания можно обойтись, так что яваскрипт для дебага придется узнать на 5.
Возьмите ASP.NET MVC 4, по нему есть куча туториалов. Для простого сайта можно обойтись без JS, достаточно знания html. Если очень хочется, контроллеры реализуйте на nemerle, язык реально очень приятный.
Ребята делают отличную и довольно уникальную штуку, но использовать ее сейчас можно рекомендовать только тем, кто хорошо понимает, как оно работает, знает плюсы и минусы технологии. Либо тем, кто может себе позволить потратить достаточно времени на поразбираться и доработать напильником. Лично я бы выбрал такую технологию для сайта вроде gmail (сложный UI, большой объем js кода, не требуется индексация поисковиками).
P.S. я тут изрядно нателепатил, так что не судите строго, если чего не угадал по вашему сообщению.
Отвечу сразу здесь, чтобы и топикстартеру и 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 кода, не требуется индексация поисковиками).
Для таких задач фреймворк как раз идеально подходит. Но, если честно, немного поделав страницы на фреймворке, я понял, что даже простые вещи удобнее делать с такой архитектурой. Единственное, что нужно решить вопрос с индексацией, т.е. добавить возможность собирать шаблоны на сервере. До этого пока далеко.
Собственно первый более менее стабильный релиз судя по всему получится выпустить до нового года. Надеюсь к этому времени получится написать хотя бы базовую документацию, а то я и сам сейчас иногда не могу вспомнить как некоторые вещи у нас делаются
I>С тонкостями MVVM не придётся разбираться, фреймворк построен так, как будто пишешь обычный шаблон. Данные сами по себе, магическим образом обновляются по мере обновления модели в коде.
Не знаю, как другие, но мне пришлось набить несколько шишек, прежде чем я въехал в саму идеологию. Принципы просты, но для их использования мне пришлось пару-тройку хороших вьюх сделать и пару раз переделать.
I>>С тонкостями MVVM не придётся разбираться, фреймворк построен так, как будто пишешь обычный шаблон. Данные сами по себе, магическим образом обновляются по мере обновления модели в коде.
Z>Не знаю, как другие, но мне пришлось набить несколько шишек, прежде чем я въехал в саму идеологию. Принципы просты, но для их использования мне пришлось пару-тройку хороших вьюх сделать и пару раз переделать.
Ну да, это с любой идеологией так. Но в целом MVVM достаточно лёгок в понимании.
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, Ziaw, Вы писали:
I>>>С тонкостями MVVM не придётся разбираться, фреймворк построен так, как будто пишешь обычный шаблон. Данные сами по себе, магическим образом обновляются по мере обновления модели в коде.
Z>>Не знаю, как другие, но мне пришлось набить несколько шишек, прежде чем я въехал в саму идеологию. Принципы просты, но для их использования мне пришлось пару-тройку хороших вьюх сделать и пару раз переделать.
I>Ну да, это с любой идеологией так. Но в целом MVVM достаточно лёгок в понимании.
Не хотите сварганить нам новое, крутое дерево для сайта? Такое все интерактивное и удобное...
VD>Привет.
VD>Не хотите сварганить нам новое, крутое дерево для сайта? Такое все интерактивное и удобное...
Почему бы и нет. Только надо вместе подумать как это сделать. Для разных людей понятия удобности и интерактивности могут отличаться.
Плюс, так по мне система РСДН сама по себе неудобна, но я знаю, что многим она нравится. Так что, если есть идеи — делись.
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. На гитхабовской страничке проекта Nemerle.Web из всех инструкций только "скачайте исходники".
Использую Visual Studio 2010 ver 10.0.40219.1
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. На гитхабовской страничке проекта Nemerle.Web из всех инструкций только "скачайте исходники".
Ничего особенного не нужно. Скачай последний Немерле с tc.rsdn.ru, и запусти NemerleWeb.Samples.sln
L>Использую Visual Studio 2010 ver 10.0.40219.1
Надо, кстати, проверить поддержку 2010 студии, у нас все на 2012 сидят.
L>>Использую Visual Studio 2010 ver 10.0.40219.1
I>Надо, кстати, проверить поддержку 2010 студии, у нас все на 2012 сидят.
В 2010 все компилируется, проверенно.
У тебя включена опция "Allow NuGet to download missing packages during build".
I>Страница проекта: http://nemerlewebsamples.apphb.com
I>Репозиторий: https://github.com/NemerleWeb/NemerleWeb
I>Все важные обновления будут поститься в этой теме. Здесь же можно постить свои вопросы и предложения/замечания.
1) Русское описание планируется или статья?
2) Какая цель проекта? Какие основные фичи? В общем обзорная статья не помешала бы...
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>1. Транслятор Nemerle -> JS
_NN>2. Связывание данных
_NN>3. Шаблоны
_NN>4. Макросы для передачи данных клиент-сервер (SignalR), для регуляции (throttling) в будущем будет для печенек (cookie)
_NN>5. Типизация JS в том числе автоматически из файлов определений TypeScript.
Насколько я понял он завязан на knockout, но там нет роутинга. Как жить дальше?
A>Насколько я понял он завязан на knockout, но там нет роутинга. Как жить дальше?
У вас старая информация
Knockout-а там нет уже давно.
Сейчас связка сделана примерно как в angular-js. Никаких observable, все просто и предельно ясно.
Скачайте проект, поиграйтесь что ли
_NN>Скачайте проект, поиграйтесь что ли
Уже какой раз пытаюсь, да все никак. Не могу понять возможности, а главное зачем?
А сайты писать можно и на php, ruby, python, javascript, ... Но это вы и без меня знаете
A>Здравствуйте, _NN_,
_NN>>Скачайте проект, поиграйтесь что ли
A>Уже какой раз пытаюсь, да все никак. Не могу понять возможности, а главное зачем?
Не могу понять ваш вопрос, что вы хотите узнать ?
Во первых проще, во вторых есть типизация.
Ну и наконец сайты на Nemerle, как тут не радоваться.
В дальнейшем будут еще DSL-и и будет вообще красота.
A>А сайты писать можно и на php, ruby, python, javascript, ... Но это вы и без меня знаете
На javascript ? Избавьте от такого счастья
A>>Уже какой раз пытаюсь, да все никак. Не могу понять возможности, а главное зачем?
_NN>Не могу понять ваш вопрос, что вы хотите узнать ?
Может есть аналог на других языках чтобы было понятней?
_NN>Во первых проще, во вторых есть типизация.
Проще чего?
_NN>Ну и наконец сайты на Nemerle, как тут не радоваться.
Это я понял.
_NN>В дальнейшем будут еще DSL-и и будет вообще красота.
A>>А сайты писать можно и на php, ruby, python, javascript, ... Но это вы и без меня знаете
_NN>На javascript ? Избавьте от такого счастья
Вы слышали по node.js?
A>Здравствуйте, ionoy, Вы писали:
A>2) Какая цель проекта? Какие основные фичи?
Цель у нас амбициозная — создать лучший в мире фреймворк для разработки веб приложений
Основные фичи NN уже перечислил, но я дополню.
Фреймворк предназначен для упрощения написания браузерных приложений, благодаря смешению клиентского и серверного кода. Такой подход позволяет избавится от большей части boilerplate кода. То есть оставить только то, что описывает логику и ни строчки больше. На данный момент мы не так уж и далеко от цели, достаточно посмотреть на исходники меню rsdn.ru.
Структура приложения состоит из так называемых юнитов. Каждый юнит содержит клиентский код (транслируемый из немерле в яваскрипт), HTML шаблон с биндингами и серверный код. Все эти три части опциональны, т.е. юнит может содержать только логику или только шаблон. По желанию можно оставить и только серверный код, но в этом нет никакого смысла Кстати, из серверного кода на сервере генерируется контроллер, а на клиенте прокси-поле для его использования.
При компиляции макрос разбирает каждый юнит и генерирует из него яваскрипт+html+серверный код, которые в последствии отдаются при запросе. Примеры юнитов можно посмотреть в проекте Samples или в вышеупомянутом меню rsdn.
Одна из интересных возможностей — это использование Немерле макросов. В браузерном коде есть часто используемые паттерны, как, например, тот же throttling. Их как раз очень удобно реализовывать с помощью макросов.
Кроме этих юнитов, для описания логики приложения теоретически не нужно ничего. Это, конечно, не означает, что отпадает необходимость писать серверную бизнес логику — данная проблема лежит вне компетенции нашего фреймворка.
Мы, кстати, на данный момент базируемся поверх ASP.NET MVC. Если у кого-то возникнет необходимость, то можно будет написать адаптер под любой другой серверный фреймворк.
I>Цель у нас амбициозная — создать лучший в мире фреймворк для разработки веб приложений
Какой у вас "Hello World"? Где у меня ошибки?
A>Какой у вас "Hello World"? Где у меня ошибки?
A>
1. В объявлении свойства на второй строчке зачем-то };
2. Класс Server нужно объявлять только тогда, когда этому юниты нужны данные с сервера — прочитать что-то из базы данных или записать обратно. При этом сериализация/десериализация происходит автоматически.
I>1. В объявлении свойства на второй строчке зачем-то };
I>2. Класс Server нужно объявлять только тогда, когда этому юниты нужны данные с сервера — прочитать что-то из базы данных или записать обратно. При этом сериализация/десериализация происходит автоматически.
Я просто качнул фреймворк, нашел пример выкинул лишнее, не понимая что делаю.
Напишите правильный
A>Я просто качнул фреймворк, нашел пример выкинул лишнее, не понимая что делаю.
A>Напишите правильный
Держи:
Только там зайди в HomeController, проверь, что возвращается именно Index
I>
I>Только там зайди в HomeController, проверь, что возвращается именно Index
Cпасибо
1) Как еще можно передавать данные во вьюху, кроме как через свойства?
2) Можно передавать dynamic? Кстати его(dynamic) поддерживает текущая версия N?
В коде есть упоминание throttle. Не смог найти в интернете. Можно ссылку что это такое и с чем его едят?
A>Здравствуйте, ionoy, Вы писали:
A>В коде есть упоминание throttle. Не смог найти в интернете. Можно ссылку что это такое и с чем его едят?
Еще не успели добавить в туториал.
Тут есть небольшое объяснение.
Вкратце это нужно, чтобы не реагировать на событие сразу, а по истечении некоторого времени.
В случае поиска мы не хотим вызывать поиск на каждый символ, это будет очень накладно, а только когда пользователь закончил ввод.
A>Здравствуйте, ionoy, Вы писали:
A>В коде есть упоминание throttle. Не смог найти в интернете. Можно ссылку что это такое и с чем его едят?
Этот паттерн обычно используют, когда нужна строка поиска. Если отсылать поисковый запрос на каждое нажатие клавиши, то получится что мы отправим как минимум столько запросов, сколько букв в слове. Такой подход может вызвать проблемы с производительностью, да и никому не нужен. Для того, чтобы избежать этой проблемы перед запросом вставляется таймаут, и если до истечения этого таймаута была нажата следующая кнопка, то таймаут сбрасывается. Таким образом запрос отсылается только на то нажатие, которое было "последним".
На самом деле название throttle не совсем корректное, более правильно называть его debounce. Но, throttle как-то более распространён, имхо.
I>Репозиторий: https://github.com/NemerleWeb/NemerleWeb
По поводу:
style-..., css-... и т.п.
Откровенно говоря этот ДСЛ не интуитивен. Для его понимания нужно долго и ундно объяснять что это и как работает.
Собственно вопрос: почему нельзя было сделать ДСЛ ближе к оригинальному ХТМЛ? Например, вместо:
писать нечто вроде:
VD>По поводу:
VD>style-..., css-... и т.п.
VD>Откровенно говоря этот ДСЛ не интуитивен. Для его понимания нужно долго и ундно объяснять что это и как работает.
VD>Собственно вопрос: почему нельзя было сделать ДСЛ ближе к оригинальному ХТМЛ? Например, вместо:
VD>
VD>писать нечто вроде:
VD>
Чёрт, пока отдыхал, на форуме целая война прошла. Жаль, что не успел поучаствовать
Тема с атрибутами, едва ли не единственная реальная проблема обсуждённая в соседнем топике. Честно говоря, я думал забить на неё до релиза и починить уже "как нибудь потом", но раз уж столько человек против расширений, то можно и сразу сделать. У меня в этом месяце будет побольше свободного времени, так что думаю сделаем.
Ну и раз уж на то пошло, то кратко отвечу на остальную критику:
Отдельные файлы с шаблонами вынести можно, но по сути это ничего не изменит, скорее только усложнит. Код останется тот же самый, но придётся выдумывать convention для названия шаблона, типа MyModel_Template1.nhtml, который будет вызываться как myModel.Template1.
По поводу того, чтобы отдавать nhtml шаблон на перевёрстку человеку, который совершенно не будет разбираться в фреймворке — это утопия. Сходите на форум к AngularJS и расскажите им, что их подход биндинга плох именно по этой причине Верстальшик не может посмотреть готовую страницу без данных, которые будут к шаблону прибинжены, а для данных проект придётся-таки собирать. Если же HTML оставлять "чистым", и манипулировать им из кода, то это уже не MVVM, и таких проектов у меня была уйма. В итоге получается знатная каша из jQuery, без какой-либо логики для постороннего человека. Зато шаблон кристально чист
MVVM (как, собственно и MVC) предлагает полностью отвязать код от представления. Т.е. представление может обращаться к коду, но не наоборот — код в идеале ничего не знает о конкретном представлении, поэтому в идеале остаётся только дистиллированная бизнес логика.
Опять же, никто не мешает взять готовый макет и практически один-в-один скопировать во View, добавив только атрибуты данных.
Про MainPage.Instance.IsActiveNode(c) я не совсем понял наезда. Да, можно было бы в каждую ноду передавать экземпляр MainPage, чтобы она могла вызывать IsActiveNode. Я выбрал sinlgeton, потому что немного выгоднее по перформансу, так как MainPage не надо передавать в отдельном цикле.
Насчёт отдельной компиляции, то тут тоже всё не так просто. Если у кого есть интерес, то можно будет обсудить.
I>Про MainPage.Instance.IsActiveNode(c) я не совсем понял наезда. Да, можно было бы в каждую ноду передавать экземпляр MainPage, чтобы она могла вызывать IsActiveNode. Я выбрал sinlgeton, потому что немного выгоднее по перформансу, так как MainPage не надо передавать в отдельном цикле.
Как минимум обращение к MainPage.Instance.IsActiveNode нужно было поместить в свойство модели представления. Ну, а лучше чтобы MainPage.Instance все же передавалось при создании. Возможно завести модельку TreeView в которой хранить все данные для дерева.
I>Насчёт отдельной компиляции, то тут тоже всё не так просто. Если у кого есть интерес, то можно будет обсудить.
Думаю, что отдельная компиляция вьюшек расположенных в отдельных файлах была бы кстати. Но пока на нее можно забить. Добавите в следующей версии. Возможно уже на базе N2.
Не выходит собрать решение.
Куда копать?
Для начала версия Nemerle самая свежая ?
http://www.nemerle.org/Downloads
_NN>http://www.nemerle.org/Downloads
Сначала была какая-то древняя. Я обновил до 1.2.0.40, но ошибка сохранилась.
_NN>>Для начала версия Nemerle самая свежая ?
_NN>>http://www.nemerle.org/Downloads
STD>Сначала была какая-то древняя. Я обновил до 1.2.0.40, но ошибка сохранилась.
А можно весь лог получить ?
Желательно сначала очистить всю папку от лишней грязи (git clean)
_NN>Здравствуйте, STDray, Вы писали:
_NN>>>Для начала версия Nemerle самая свежая ?
_NN>>>http://www.nemerle.org/Downloads
STD>>Сначала была какая-то древняя. Я обновил до 1.2.0.40, но ошибка сохранилась.
_NN>А можно весь лог получить ?
_NN>Желательно сначала очистить всю папку от лишней грязи (git clean)
Можно, но уже не нужно. У меня какая-то шляпа с папкой проекта произошла. Забрал последнюю версию в новую директорию и все собралось. Спасибо за помощь.
STD>Можно, но уже не нужно. У меня какая-то шляпа с папкой проекта произошла. Забрал последнюю версию в новую директорию и все собралось. Спасибо за помощь.
Кстати если хотите попробовать шаблоны для NemerleWeb.
Нужно запустить спец команду на сайте внизу: www.nemerleweb.com/
Тогда можно будет легко создавать новые проекты на NemerleWeb
_NN>Нужно запустить спец команду на сайте внизу: www.nemerleweb.com/
_NN>Тогда можно будет легко создавать новые проекты на NemerleWeb
Я попробую. Но на данный момент, мне надо было протестировать какой-то уже готовый проект. Я начитался какой-то темы, что верстальщики страдают от студии, компиляций и релоадов, потому написал конпелирующий веб-сервер. А сэмплы немемрлевеб собираться отказались, потом оказалось, что и студия их собрать не может. Но сейчас все нормально.
_NN>Кстати если хотите попробовать шаблоны для NemerleWeb.
_NN>Нужно запустить спец команду на сайте внизу: www.nemerleweb.com/
_NN>Тогда можно будет легко создавать новые проекты на NemerleWeb
А почему у вас на сайте http://www.nemerleweb.com/ работает только ссылка на сайт Немерле, а кнопки — нет?