Здравствуйте, ionoy, Вы писали:
I>Если я не ошибаюсь, то у Xamarin'а не было некоммерческой лицензии
Была, лично у них бесплатный ключик получал.
I>Но может вы и правы, на данном этапе это цена несколько высоковата. Может региональные скидки добавить?
Достаточно сложно проконтролировать, откуда человек платит. Разве что проверять BIN-ы при оплате картой.
Всё ещё рекомендую найти продажника. Ну и главное, чтобы не было вот так.
Здравствуйте, IT, Вы писали: IT>Как насчёт циклов?
В прошлом году делали систему для СИКН(система измерения качества нефти).
Там очень нехилая система отчетности. Данные отчетов хранились в БД в json-строках (не мы так решили, так "исторически сложилось")
И мы ее делали на WPF.
В WPF есть такая штука, называется FlowDocument — тот же XAML, но для разметки документов. Проблема в том, что она декларативная и не гибкая.
К тому же, в нашем случае, форма отчетов и исходных данных постоянно менялись и надо было менять их чуть ли не на лету.
Так вот, нам пришлось строить препроцессор XAML чтобы впихнуть туда циклы и парсер jsona. В итоге он разворачивал все это в нативный XAML для дальнейшей печати.
Примеры использования:
<Paragraph Text="<!--{d.f}-->" /> //этот кусок формировал параграф, куда вставлял из jsonа значение узла d.f
А если надо было нарисовать список параграфов, то синтаксис был такой: <!--arr{//arr — это путь к массиву объектов в json
<Paragraph Text="<!--{Name}-->" /> //Name — это поле в объекте }->
Paragraph дан для примера. В основном в цикле строились таблицы.
Потом туда добавилась простенькая логика, макросы и прочее. В итоге получился сплошной костыль. Но работал.
Позже я преобразовал это в лиспо-подобный язык, где можно было наращивать функционал из коробки.
И все это транслировалось в тот-же XAML.
Пример
А вот и цикл
P.S. Написал исключительно ради справедливости. Отчеты — штука специфическая. Но циклы все-таки иногда нужны, даже в разметке.
Re[3]: Хочу похвастаться! Первый язык на основе Nitra - AMMY
Здравствуйте, MAMOHT, Вы писали:
MAM>P.S. Написал исключительно ради справедливости. Отчеты — штука специфическая. Но циклы все-таки иногда нужны, даже в разметке.
Хороший пример, я как-то сразу не подумал про FlowDocument. С другой стороны не совсем понятно как Ammy будет резолвить ваши циклы в compile time. Вы то скорее всего парсили в рантайме, создавали нужный XAML и его уже загружали.
Есть вариант создать невидимый псевдоэлемент, который будет принимать биндинг + шаблон. По мере изменения биндинга можно создавать элементы в родительском контроле. Но тут можно целую кучу граблей собрать, а выхлоп небольшой.
Здравствуйте, MAMOHT, Вы писали:
MAM>P.S. Написал исключительно ради справедливости. Отчеты — штука специфическая. Но циклы все-таки иногда нужны, даже в разметке.
Вот! Влад, где ты там? Послушай умного человека!
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Хочу похвастаться! Первый язык на основе Nitra - AMMY
Здравствуйте, ionoy, Вы писали:
I>Здравствуйте, MAMOHT, Вы писали:
MAM>>P.S. Написал исключительно ради справедливости. Отчеты — штука специфическая. Но циклы все-таки иногда нужны, даже в разметке.
I>Хороший пример, я как-то сразу не подумал про FlowDocument. С другой стороны не совсем понятно как Ammy будет резолвить ваши циклы в compile time.
Кстати, да. Про compile time я как-то не подумал. Когда клепаю формы, про циклы еще ни разу не вспомнил. Возможно, если бы в тот раз у нас было больше опыта и времени, то выкрутились бы стандартными способами.
Здравствуйте, IT, Вы писали:
MAM>>P.S. Написал исключительно ради справедливости. Отчеты — штука специфическая. Но циклы все-таки иногда нужны, даже в разметке.
IT>Вот! Влад, где ты там? Послушай умного человека!
У него свой язык генераторов отчетов. XAML там не более чем выходной формат. И он отсутствие циклов в ХАМЛ-е ему не помешало генерировать ХМАЛ.
Но подобное можно реализовать и в ХАМЛ-е или Амми простым добавлением контрола-потворителя (репитера).
Надо как-то различать язык разметки и язык генерации чего либо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Хочу похвастаться! Первый язык на основе Nitra - AMMY
Здравствуйте, MAMOHT, Вы писали:
MAM>Кстати, да. Про compile time я как-то не подумал. Когда клепаю формы, про циклы еще ни разу не вспомнил. Возможно, если бы в тот раз у нас было больше опыта и времени, то выкрутились бы стандартными способами.
А почему бы вместо циклов (я не про твой лиспо-подобный язык, а про XAML) не использовать специальный контрол-повторитель?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Хочу похвастаться! Первый язык на основе Nitra - AMMY
MAM>>Кстати, да. Про compile time я как-то не подумал.
VD>А почему бы вместо циклов (я не про твой лиспо-подобный язык, а про XAML) не использовать специальный контрол-повторитель?
Да не, мне ничего объяснять не надо. Перепутал задачи. В крайнем случае, можно нагенерить прямо в коде (например столбцы таблицы для помесячного отображения). Перегружать из-за этого язык РАЗМЕТКИ не стОит. Получится аля NemerleWeb, и его опять заклюют сторонники "логика отдельно, представление отдельно". И правильно сделают, кстати. Циклы в разметке портят декларативность.
Здравствуйте, VladD2, Вы писали:
VD>AMMY — XAML с человеческим лицом созданный с использованием Nitra и Nemerle.
VD>Автор: ionoy. VD>Сайт языка: http://www.ammyui.com Там много примеров, доки, видео. VD>Видео с демонстрацией процесса разработки: https://vimeo.com/198873582
VD>Особенности языка: VD>1. Вместо XML, на котором основан XAML, в AMMY используется синтаксис базирующийся на JSON.
Сомнительное преимущество, количество сущностей то же, читабельность не ощутимо лучше. Особенно на больших формах.
Причем в ущерб функциональности, многие важные фичи не поддерживаются как пишет сам автор.
VD>2. Язык строготипизированный.
Это не преимущество с существующими.
VD>3. Для AMMY имеется поддержка IDE (подсветка, автодополение, навигация по коду и т.п.). VD>4. Поддерживает миксины (аналог макросов для XAML). Повышает производительность руда и повторного использования кода.
Тоже не преимущество с существующими решениями все это есть.
VD>5. Возможность менять GUI прямо во время исполнения.
Тоже во всех UI фреймворках это есть или я не очень понял что автор хочет сказать.
Даже на WinAPI можно убрать кнопку и показать кнопку, увеличить/уменьшить окно или контрол, не говоря уже о возможностях более высокоуровневых решений.
Если имеется ввиду дизайнить в рантайме , то в студии это вроде как давно есть, запускаешь приложение и редактируешь — сразу видишь результат.
Я за интересные решения для UI, но в данном случае не понятно зачем это все, как это увеличит производительность моего труда особенно с учетом что многие фичи доступные в XAML не поддерживаются, а JSON XMLя не слаще, те же яйца вид сбоку со своими плюсами и минусами.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Раз про Немерле никто ничё не пишет, напишу про Ammy пару размышлизмов.
1. Ammy как хелпер — превосходно. Mixin и Alias — громадная помощь неуклюжему WPF (вот чем надо было MS заниматься, а не байндинги с триггерами мусолить).
2. При всём моём презрении к раздутому XML, оказалось, что JSON здесь не намного лучше. Есть что-то стилистически неуклюжее в том, что разные по сути элементы выглядят одинаково. Посмотрите на иллюстрацию вверху — казалось бы, StackPanel содержит вполне однотипные с ним контролы внутри — два TextBlock'а. Однако у второго TextBlock'а внутри уже идут не элементы, а инициализация пропертей! Но выглядят-то они абсолютно идентично — внутри скобок. Ещё более наглядный пример:
Ширина, высота,... что?? ТекстБлок? А он там с какого перепугу?
Понятно, что "умный парсер" всё расскажет и покажет, но это неправильно. Распечатайте ч/б эмми-код и поймёте, что у вас нет никакого желания разбираться, кто есть кто.
Я тоже не один день размышлял, как можно красиво-декларативно задавать UI (и тоже попался на удочку JSON), но решил, что тут надо думать глубже и создавать UI-язык без оглядки на существующие решения. Прям вот смело брать и запиливать свой DSL, с конкретной заточкой на сущности "контрол проперть-значение коллекция-контролов". Ну и сахар не забывать, конечно.
Здравствуйте, Kolesiki, Вы писали:
K>Image: HQlYNh4.png
K>Ширина, высота,... что?? ТекстБлок? А он там с какого перепугу?
Разные люди по-разному визуализируют дерево контролов UI. Дети контрола это всего лишь ещё одно свойство. Его можно записать явно, как Children = {}, а можно принять договорённость, что все элементы находящиеся внутри других, будут автоматически добавлены в Children. Суп из свойств и детей корёжит только по-началу, особенно после XML. Там ведь свойста обычно задаются атрибутами, а дети внутренними нодами. Но по факту ведь весь XAML превращается в "элемент.свойство = ...". И где находится присвоение детей, а где "обычных" свойств, совсем не важно.
K>Понятно, что "умный парсер" всё расскажет и покажет, но это неправильно. Распечатайте ч/б эмми-код и поймёте, что у вас нет никакого желания разбираться, кто есть кто.
Я очень быстро привык к тому, что обычные свойства заканчиваются двоеточием, а контролы имеют вид "ИмяЭлемента {}". Но и язык то я придумывал в соответствии с собственным пониманием прекрасного. Вполне вероятно, что другой человек и через пол года будет плеваться на синтаксис.
K>Я тоже не один день размышлял, как можно красиво-декларативно задавать UI (и тоже попался на удочку JSON), но решил, что тут надо думать глубже и создавать UI-язык без оглядки на существующие решения. Прям вот смело брать и запиливать свой DSL, с конкретной заточкой на сущности "контрол проперть-значение коллекция-контролов". Ну и сахар не забывать, конечно.
Собственно, Ammy — это и есть отдельный UI язык. Некоторые оглядки там всё-таки были (например QML). Но в целом, я думал о том как создать язык именно для замены XAML, без компромиссов. С удовольствием обсужу альтернативные варианты, просто хотя бы из интереса к теме.
Здравствуйте, ionoy, Вы писали:
K>>Ширина, высота,... что?? ТекстБлок? А он там с какого перепугу?
I> Суп из свойств и детей корёжит только по-началу, особенно после XML
Вот именно — "поначалу"! Т.е. свежий, незамутнённый взгляд сразу цепляется за "неправильное".
Я согласен, привыкнуть можно к чему-угодно, даже к Перлу но вот моё мнение таково, что если тебе КАК ЧЕЛОВЕКУ сложно читать код, то и парсеру тоже будет несладко.
Мой намёк очевиден: сделать как-то разграничение — отдельно проперти, отдельно чилдренята. И вовсе не обязательно придерживаться какой-то узкой парадигмы (как в XML "всё есть узел + атрибуты") — мы можем вертеть синтакисом как угодно, вплоть до юникода и эмодзи.
I>Я очень быстро привык к тому, что обычные свойства заканчиваются двоеточием, а контролы имеют вид "ИмяЭлемента {}"
Вот-вот! Т.е. сначала мы читаем "нечто именованное" и только потом, по привычному имени или заглянув вперёд, понимаем — ага, это проперть! Это не есть хорошо. Я бы даже пошёл по пути Перла, где $ и @ определяют разные сущности. Хотя может это и не понадобится, если продумать синтаксис дочерних элементов.
I>Собственно, Ammy — это и есть отдельный UI язык
Неа. Ты же сам на странице пишешь "JSON-like syntax". И это прекрасно в том плане, что тысячи людей, знающих JSON, могут легко влиться в проект. Но проблема как раз в самом JSON'е — это немного "не то". Для объектов (как абстрактных наборов свойств) — прекрасно подходит. Но для UI-языка — нет, потому что "язык описания интерфейса" 100% потребует множество сахара (чтобы быть красивым и лаконичным). JSON и так весьма краткий язык и именно поэтому в нём очень мало простора для сокращений.
I> С удовольствием обсужу альтернативные варианты, просто хотя бы из интереса к теме.
Я эту тему тоже не раз касаюсь, когда выбешивает WPF Но пока рисую лишь черновики. Если что сформулирую длиннее абзаца — обязательно поделюсь.
Здравствуйте, Kolesiki, Вы писали:
K>Я тоже не один день размышлял, как можно красиво-декларативно задавать UI (и тоже попался на удочку JSON), но решил, что тут надо думать глубже и создавать UI-язык без оглядки на существующие решения. Прям вот смело брать и запиливать свой DSL, с конкретной заточкой на сущности "контрол проперть-значение коллекция-контролов". Ну и сахар не забывать, конечно.
Проблема в том, что под языком должна лежать какая-то реализация. Лично я согласен, что для описания нужен полноценный DSL без переиспользования универсальных языков вроде JSON-а или XML-я. Но DSL должен выражать некую семантику. И тут без использования чего-то вроде WPF-не обойтись. Ну, а библиотека уже будет диктовать свои решения и ограничения.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>Я очень быстро привык к тому, что обычные свойства заканчиваются двоеточием, а контролы имеют вид "ИмяЭлемента {}".
Дык и к XAML-у привыкают. Но это не от хорошей жизни. Возможно имело смысл ввести специальное ключевое слово и перейти на синтаксис более близки к присвоению в обычных императивных язках.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
K>Я тоже не один день размышлял, как можно красиво-декларативно задавать UI (и тоже попался на удочку JSON), но решил, что тут надо думать глубже и создавать UI-язык без оглядки на существующие решения. Прям вот смело брать и запиливать свой DSL, с конкретной заточкой на сущности "контрол проперть-значение коллекция-контролов". Ну и сахар не забывать, конечно.
K>>Я тоже не один день размышлял, как можно красиво-декларативно задавать UI (и тоже попался на удочку JSON), но решил, что тут надо думать глубже и создавать UI-язык без оглядки на существующие решения. Прям вот смело брать и запиливать свой DSL, с конкретной заточкой на сущности "контрол проперть-значение коллекция-контролов". Ну и сахар не забывать, конечно.
M>SwiftUI же. Хотя Swift как язык еще то гуанецо.