Решаю задачу создания UI библиотеки, основное требование:
1) Декларативность описания UI, чтоб была возможность рендерить всякие html, svg и т.д, система байндингов типа как в wpf, поддержка стилей и шаблонов как в wpf
сейчас делаю загрузку описания UI из xml файла, пока решил далеко не ходить и полностью содрал семантику и синтаксис xaml и MarkupExtension из wpf.
Как известно любой xaml загружается в две стадии:
1) парсинг и загрузка данных
2) инстанциация сцены
такое разделение вызвано тем, что деревья элементов, которые описаны в шаблонах не могут быть инстанциированы сразу, а только при присоединении к какому-то контролу, т.е. по сути xaml файл — описание фабрики по созданию контролов, у меня возникла такая идея: при парсинге можно формировать Expression<Func<IServiceProvider, object>> компилировать его и сохранять, а при создании сцены просто вызывать его и все.
Прошу прокомментировать такой подход, возможно можно использовать какие-то специфические фичи Nemerle, чтоб можно было решить эту задачу более красиво.
Здравствуйте, Visor2004, Вы писали:
V>Решаю задачу создания UI библиотеки, основное требование:
V>1) Декларативность описания UI, чтоб была возможность рендерить всякие html, svg и т.д, система байндингов типа как в wpf, поддержка стилей и шаблонов как в wpf
V>сейчас делаю загрузку описания UI из xml файла, пока решил далеко не ходить и полностью содрал семантику и синтаксис xaml и MarkupExtension из wpf.
Мне кажется, что xaml оправдан только если будет возможность использовать штатный редактор студии. Xml не очень годен, как для написания человеком так и для чтения человеком. Взгляни лучше на HtmLayout и QML
V>Прошу прокомментировать такой подход, возможно можно использовать какие-то специфические фичи Nemerle, чтоб можно было решить эту задачу более красиво.
Суть подхода описано как-то скомкано, экспрешен зачем, для рантайм компиляции?
Здравствуйте, Visor2004, Вы писали:
V>Прошу прокомментировать такой подход, возможно можно использовать какие-то специфические фичи Nemerle, чтоб можно было решить эту задачу более красиво.
Думаю тебе стоило сюда написать до того как начал писать код.
Там написано про веб, но подход подходит для любого ГУИ. Re[2]: Веб фрэймворк для Nemerle
Здравствуйте, Ziaw, Вы писали:
Z>Мне кажется, что xaml оправдан только если будет возможность использовать штатный редактор студии. Xml не очень годен, как для написания человеком так и для чтения человеком. Взгляни лучше на HtmLayout и QML
да это просто для тестов, мне привычно работать с xaml, поэтому тестовый front-end у меня подобие xaml сейчас
Z>Суть подхода описано как-то скомкано, экспрешен зачем, для рантайм компиляции?
Да, разметкой в wpf можно пользоваться двумя способами
1) в рантайме грузится разметка в текстовом виде, парсится и создается сцена
2) на этапе компиляции, разметка парсится и AST сохраняется в файл ресурсов, в дальнейшем при работе с ней парсинга не происходит
Я решил немного этот процесс соптимизировать и сохранять не AST разметки, а скомпилированный код в сборке, который умеет инстанциировать сцену, для этого я паршу текстовое описание сцены, строю по нему Expression, который я могу скомпилировать сборку и сохранить или выполнить когда мне захочется, не теряя в дальнейшем время на парсинг сцены и компиляцию.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Visor2004, Вы писали:
V>>Прошу прокомментировать такой подход, возможно можно использовать какие-то специфические фичи Nemerle, чтоб можно было решить эту задачу более красиво. WH>Думаю тебе стоило сюда написать до того как начал писать код. WH>Там написано про веб, но подход подходит для любого ГУИ. WH>Re[2]: Веб фрэймворк для Nemerle
Здравствуйте, Visor2004, Вы писали:
V>пока решил далеко не ходить и полностью содрал семантику и синтаксис xaml и MarkupExtension из wpf.
Умоляю, не повторяй ошибки MS-а — XML следует послать ровно в дупу да поглубже! Я этого Xaml-я на работе уже накушался по самое немогу — приемлемо будет что угодно другое похожее на JSON или, скажем, на выражения инициализации C#/Nemerle.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, Visor2004, Вы писали:
V>>пока решил далеко не ходить и полностью содрал семантику и синтаксис xaml и MarkupExtension из wpf.
H>Умоляю, не повторяй ошибки MS-а — XML следует послать ровно в дупу да поглубже! Я этого Xaml-я на работе уже накушался по самое немогу — приемлемо будет что угодно другое похожее на JSON или, скажем, на выражения инициализации C#/Nemerle.
ну в отличие от MS я не собираюсь прибивать потроха библиотеки гвоздями к xaml, разметка — front end. Вообще основная часть разметки будет на html/svg делаться в продакшене
Здравствуйте, Visor2004, Вы писали:
V>1) Декларативность описания UI, чтоб была возможность рендерить всякие html, svg и т.д, система байндингов типа как в wpf, поддержка стилей и шаблонов как в wpf
Не очень ясно о чем конкретно идет речь. Если это задумка создать некий фрэймворк облегчающий создание UI в html, то один разговор. Если ты хочешь создать аналог WPF — то другой. Что ты хочешь получить в итоге?
V>сейчас делаю загрузку описания UI из xml файла, пока решил далеко не ходить и полностью содрал семантику и синтаксис xaml и MarkupExtension из wpf.
Присоединяюсь к тем кто советует не использовать XML для описания. Если уж ты выбрал Немерл в качестве средства реализации, то логично было бы соорудить свой язык, который можно было бы читать человеку без боли в глазах.
V>Как известно любой xaml загружается в две стадии: V>1) парсинг и загрузка данных V>2) инстанциация сцены
Тут все зависит от ответа на мой первый вопрос. Но, опять же соглашусь с Вольфхаундом, что для любого UI реактивный подход (который и используется в WPF) — лучший подход.
Ты видел Nemerle.WUI.Reactive?
Это прототип подобной библиотеки. Если интересно, могу раскрыть детали.
V>такое разделение вызвано тем, что деревья элементов, которые описаны в шаблонах не могут быть инстанциированы сразу, а только при присоединении к какому-то контролу, т.е. по сути xaml файл — описание фабрики по созданию контролов, у меня возникла такая идея: при парсинге можно формировать Expression<Func<IServiceProvider, object>> компилировать его и сохранять, а при создании сцены просто вызывать его и все.
Я не понимаю, зачем вообще нужно использовать деревья выражений? Их использование имеет смысл только, требуется преобразование кода в рантайме (как в случае запросов к БД).
Если описание доступно во время разработки (а с ГУИ всегда так), то смысла в использовании деревьев выражений нет. Немерловый АСТ более гибок и не требует затрат времени на этапе выполнения.
Опиши свою идею по подробнее. И за одно объясни чем не устраивают имеющиеся библиотеки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Не очень ясно о чем конкретно идет речь. Если это задумка создать некий фрэймворк облегчающий создание UI в html, то один разговор. Если ты хочешь создать аналог WPF — то другой. Что ты хочешь получить в итоге?
Да, надо аналог wpf
V>>сейчас делаю загрузку описания UI из xml файла, пока решил далеко не ходить и полностью содрал семантику и синтаксис xaml и MarkupExtension из wpf. VD>Присоединяюсь к тем кто советует не использовать XML для описания. Если уж ты выбрал Немерл в качестве средства реализации, то логично было бы соорудить свой язык, который можно было бы читать человеку без боли в глазах.
front-end будет сменный, это не такая большая проблема одну и ту же семантику можно представить десятком способов.
VD>Ты видел Nemerle.WUI.Reactive? VD>Это прототип подобной библиотеки. Если интересно, могу раскрыть детали.
Я посмотрел исходники... чем это принципиально отличается от мсовского разора?
VD>Я не понимаю, зачем вообще нужно использовать деревья выражений? Их использование имеет смысл только, требуется преобразование кода в рантайме (как в случае запросов к БД).
деревья выражений — один из способов реализации идеи компиляции разметки UI в программный код. написали разметку, которая после обработки компилятором трансформируется в сборку с одним статическим классов, у которого есть фабричный метод, который создает сцену.
VD>Если описание доступно во время разработки (а с ГУИ всегда так), то смысла в использовании деревьев выражений нет. Немерловый АСТ более гибок и не требует затрат времени на этапе выполнения.
как работать с ExpressionTree я уже знаю, а немерловый AST — для меня темный лес
VD>Опиши свою идею по подробнее. И за одно объясни чем не устраивают имеющиеся библиотеки.
Идея — сделать более простой аналог wpf, который будет использован для создания UI в игровом проекте.
Здравствуйте, Visor2004, Вы писали:
V>Да, надо аналог wpf
А почему не взять wpf или не сделать обертку для него?
VD>>Ты видел Nemerle.WUI.Reactive? VD>>Это прототип подобной библиотеки. Если интересно, могу раскрыть детали.
V>Я посмотрел исходники... чем это принципиально отличается от мсовского разора?
Тем что это скорее WPF для Веба. Лучше скомпилируй и запусти проект, сам все поймешь.
Общая идея заключается в том, что этот решение использует паттерн MVVM, а не базовый MVC. Кроме того он рассчитан на создание динамического клиента (в смысле с богатым интерактивым UI).
Данный подход можно расширить на GUI. Нужно только абстрагировать часть отвечающую за описание и генерацию представления. Учитывая что эта часть почти не реализована — это будет не сложно .
V>деревья выражений — один из способов реализации идеи компиляции разметки UI в программный код. написали разметку, которая после обработки компилятором трансформируется в сборку с одним статическим классов, у которого есть фабричный метод, который создает сцену.
Дык подобную компиляцию и трансформацию лучше делать во время компиляции. Деревья же выражений работают исключительно на стадии выполнения. А это значит — тормоза при загрузки и худший контроль ошибок.
В общем, собери и запусти Nemerle.WUI.Reactive. Погляди насколько он интерактивен и при этом проверки делаются во время компиляции.
VD>>Если описание доступно во время разработки (а с ГУИ всегда так), то смысла в использовании деревьев выражений нет. Немерловый АСТ более гибок и не требует затрат времени на этапе выполнения.
V>как работать с ExpressionTree я уже знаю, а немерловый AST — для меня темный лес
За одно и разберешься.
На самом деле работать с немерловым АСТ проще и удобнее, так как есть квази-цитирование, т.е. код не придется описывать в виде АСТ. А вот с формированием деревьев выражений точно будут проблемы.
VD>>Опиши свою идею по подробнее. И за одно объясни чем не устраивают имеющиеся библиотеки.
V>Идея — сделать более простой аналог wpf, который будет использован для создания UI в игровом проекте.
Что-то мне кажется, что проще было бы сделать надстройку над wpf. Или wpf не работает на тех платформах где планируется выполнять игру?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>А почему не взять wpf или не сделать обертку для него?
iOS, Android
VD>Дык подобную компиляцию и трансформацию лучше делать во время компиляции. Деревья же выражений работают исключительно на стадии выполнения. А это значит — тормоза при загрузки и худший контроль ошибок. VD>В общем, собери и запусти Nemerle.WUI.Reactive. Погляди насколько он интерактивен и при этом проверки делаются во время компиляции. VD>>>Если описание доступно во время разработки (а с ГУИ всегда так), то смысла в использовании деревьев выражений нет. Немерловый АСТ более гибок и не требует затрат времени на этапе выполнения.
если написать свой build-task, то стадия компиляции приложения для него будет как раз стадией выполнения, а в рантайме вообще никаких потерь производительности, потому что просто поднимаем сборку из ресурсов и выполняем код.
VD>За одно и разберешься. VD>На самом деле работать с немерловым АСТ проще и удобнее, так как есть квази-цитирование, т.е. код не придется описывать в виде АСТ. А вот с формированием деревьев выражений точно будут проблемы.
Я не упираюсь рогом в Expression Trees, это просто как один из вариантов, который я придумал, я потому и написал сюда, что может кто-то предложит лучший. Но по работе с AST Nemerle нет ни документации, ни примеров, и нет времени разбираться в таких сложных вещах методом тыка, проект у меня все же коммерческий.
Здравствуйте, Visor2004, Вы писали:
V>Я не упираюсь рогом в Expression Trees, это просто как один из вариантов, который я придумал, я потому и написал сюда, что может кто-то предложит лучший. Но по работе с AST Nemerle нет ни документации, ни примеров, и нет времени разбираться в таких сложных вещах методом тыка, проект у меня все же коммерческий.
Прикол в том что с АСТ немерла благодаря квазицитированию ты разберешься методом тыка быстрее чем с ET читая доки.
Примеров полно например тут: https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser/Nemerle.Peg.Macros/Compiler/RuleCompiler
Да и вообще просто делаешь поиск в исходниках вот такой закорючки <[ и получаешь тонны разнообразных примеров.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Visor2004, Вы писали:
V>>Я не упираюсь рогом в Expression Trees, это просто как один из вариантов, который я придумал, я потому и написал сюда, что может кто-то предложит лучший. Но по работе с AST Nemerle нет ни документации, ни примеров, и нет времени разбираться в таких сложных вещах методом тыка, проект у меня все же коммерческий. WH>Прикол в том что с АСТ немерла благодаря квазицитированию ты разберешься методом тыка быстрее чем с ET читая доки. WH>Примеров полно например тут: https://github.com/rsdn/nemerle/tree/master/snippets/peg-parser/Nemerle.Peg.Macros/Compiler/RuleCompiler WH>Да и вообще просто делаешь поиск в исходниках вот такой закорючки <[ и получаешь тонны разнообразных примеров.
В то и дело, что тонны вместо того, чтобы четко получить информацию мне придется лопатить тонны примеров. Но в принципе бегло проглядев исходники с квазитированием понятно. Но как мне имея PExpr, сделать из него сборку, какое API для этого есть?
Здравствуйте, Visor2004, Вы писали:
V>В то и дело, что тонны вместо того, чтобы четко получить информацию мне придется лопатить тонны примеров. Но в принципе бегло проглядев исходники с квазитированием понятно. Но как мне имея PExpr, сделать из него сборку, какое API для этого есть?
Самый простой способ создать макрос и им сгенерировать классы.
Макрос может читать произвольные файлы.
В качестве примера посмотри макрос Resource.
Если я тебя правильно понял он занимается почти тем же что тебе надо.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Visor2004, Вы писали:
V>iOS, Android
Хм. А на iOS Моно работает?
V>если написать свой build-task, то стадия компиляции приложения для него будет как раз стадией выполнения,
Не будет. Деревья выражений не подразумевают сериализацию полученного IL-а.
V>а в рантайме вообще никаких потерь производительности, потому что просто поднимаем сборку из ресурсов и выполняем код.
С деревьями выражений так не выйдет. Да и не нужны они тут вовсе. Не нужен так же никакой build-task. Все что тебе нужно — это написать свой ДСЛ который во время компиляции будет преобразовываться в исполняемые код.
V>Я не упираюсь рогом в Expression Trees, это просто как один из вариантов, который я придумал, я потому и написал сюда, что может кто-то предложит лучший.
Ну, вот они здесь точно ни каким боком не уперлись. Только проблемы дополнительные создашь.
V>Но по работе с AST Nemerle нет ни документации, ни примеров, и нет времени разбираться в таких сложных вещах методом тыка, проект у меня все же коммерческий.
Ну, если у тебя нет времени разбираться в языке, то стоит подумать о том чтобы писать все на том языке который ты знаешь.
Что касается документации, то все что нужно есть. А будут вопросы, можешь их здесь задать.
Выбирать же Немерл для задач требующих метапрограммироание и при этом возиться с деревьями выражений вместо макросов просто неразумно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Хм. А на iOS Моно работает?
да
V>>если написать свой build-task, то стадия компиляции приложения для него будет как раз стадией выполнения,
VD>Не будет. Деревья выражений не подразумевают сериализацию полученного IL-а.
http://msdn.microsoft.com/en-us/library/dd728224.aspx
VD>Что касается документации, то все что нужно есть. А будут вопросы, можешь их здесь задать. VD>Выбирать же Немерл для задач требующих метапрограммироание и при этом возиться с деревьями выражений вместо макросов просто неразумно.
безусловно, но есть такие вещи как риски, я решил попробовать стандартный механизм, если он меня не устроит буду, конечно пробовать альтернативы.
VD>Ну, если у тебя нет времени разбираться в языке, то стоит подумать о том чтобы писать все на том языке который ты знаешь.
оч. смешно, я начал работать с Nemerle не для того, чтобы забить через несколько месяцев.
Здравствуйте, Visor2004, Вы писали:
V>В то и дело, что тонны вместо того, чтобы четко получить информацию мне придется лопатить тонны примеров. Но в принципе бегло проглядев исходники с квазитированием понятно. Но как мне имея PExpr, сделать из него сборку, какое API для этого есть?
Дык макросы для этого и используются. Код добавляется в ту же сборку.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Visor2004, Вы писали:
V>безусловно, но есть такие вещи как риски, я решил попробовать стандартный механизм, если он меня не устроит буду, конечно пробовать альтернативы.
Для немерла стандартный механизм — это макросы. А вот разные там деревья выражений уже через макросы реализуются.
VD>>Ну, если у тебя нет времени разбираться в языке, то стоит подумать о том чтобы писать все на том языке который ты знаешь. V>оч. смешно, я начал работать с Nemerle не для того, чтобы забить через несколько месяцев.
Тогда выброси идею с деревьями выражений (тем более что их поддержки может банально не быть на телефонах) и изучи мкакросы. Начни с мелких примеров, а там перейдешь к более серьезным. Мы тебе подскажем, если что-то будет не ясно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Visor2004, Вы писали:
V>>В то и дело, что тонны вместо того, чтобы четко получить информацию мне придется лопатить тонны примеров. Но в принципе бегло проглядев исходники с квазитированием понятно. Но как мне имея PExpr, сделать из него сборку, какое API для этого есть?
VD>Дык макросы для этого и используются. Код добавляется в ту же сборку.
мне нужно уметь для каждого файла с разметкой делать отдельную сборку, которую потом ложить в ресурсы компилируемой.
Здравствуйте, Visor2004, Вы писали:
V>мне нужно уметь для каждого файла с разметкой делать отдельную сборку, которую потом ложить в ресурсы компилируемой.
Это решаемая проблема. Можно создать несколько проектов с разными настройками и подключить к ним одни и те же файлы. А можно один и тот же проект компилировать под разные платформы. В общем — это уже технический вопрос. А все технические вопросы решаемые. Ты сначала определись с вопросами архитектурными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
— приемлемо будет что угодно другое похожее на JSON или, скажем, на выражения инициализации C#/Nemerle.
.