roboforum.ru

...и он с легкостью напишет такой жава-скрипт, который будет на самом интересном месте подвешивать девайс

Точно с такой же легкостью ошибку можете допустить вы в своем коде. =) Отестируете и все.

Само собой. Только за чужие грабли отвечать не хочется.
Да и не дизайнерское это дело - код писать Пусть свои картинки рисует, шрифты, верстает и т.п.

Пусть свои картинки рисует, шрифты, верстает и т.п.

Ну уж нет. Если он не должен код писать, то и HTML ему не надо трогать. Пусть в фотошопе все готовит.
Флешеры вон нормально все пишут. Не понимаю чего бояться.

Да, и HTML в идеале не надо трогать - я согласен.

Это они игрушки пишут, а как только встанет вопрос о банкомате, кардиостимуляторе или управления газовой турбиной, сразу встанет вопрос об отделении критических функций от картинок.
Например, этот девайс по требованиям даже выключить невозможно, когда захочется - он обязан корректно завершить все свои "дела".

Но суть не в этом - я пока не очень понимаю, куда вы клоните - вы меня склоняете к модели "ВижуалБейсика"? Или все же XAMLа?

Добавлено спустя 6 минут 26 секунд:
В общем, хочется сделать "визуализатор" как можно более "тонкий", но как можно более гибкий.

Я думаю, что все-таки это модель с "биндингом", только набор элементов управления очень широкий придется делать.

Но суть не в этом - я пока не очень понимаю, куда вы клоните.

Мне нравится как сделан XAML.

Мне тоже нравится эта идеология... без исполняемого кода в описании интерфейса...
хотя некоторые вещи я не очень понимаю, как реализовать красиво.

Простые кнопки, индикаторы, слайдеры - понятно.
(Их много и кодом их перегружать ну совсем никому не нужно - ни мне, ни тем более юзеру - их надо связать с предопределенными переменными безо всякого кода).

Но, например...
из-за того, что настроек и вариантов много, я хочу сделать также и "комбо",
в котором можно было бы выбрать сохраненные на диске предустановки
(и возможно их потом скорректировать другими элементами UI)
или вбить новое название для нового набора установок,
(которые будут сохранены на диске)...
Чтобы типовые настройки можно было быстро вызывать.

Ну например есть меню ресторана - можно выбрать по пунктам
"первое", "салат", "второе", "гарнир", "напиток", "десерт" и т.п.
Но при этом есть "комбо", в котором можно выбрать "Комплексный обед №1"
(и все пункты сами встанут как надо), а потом поменять например "рыбу" на "курицу"
и сохранить под новым именем как "Ужин язвенника Васи"...

Вот в концепции "биндинга" такая процедура мне кажется уж очень корявой.
Ну, по крайней мере, неочевидной с моей точки зрения.

ксамл это это всего-лишь язык разметки. когда на форму кидают, к примеру кнопку и даблкликают, создаётся обработчик события. это уже ни разу не mvvm. для этого есть интерфейс ICommand. с биндингом такая же ситуация - он полезен, но толку от него 0, если неправильно использовать. а приведеный пример на самом деле элементарно реализуем. бинданг в данном случае всего-лишь один из нужных кирпичиков, который нужно понимать как и зачем использовать.

Когда "на форму кидают и даблкликают" - это никак не "язык"

И еще, мне-то в общем по барабану, mvvm оно или не mvvm. Лишь бы поставленную задачу решало.

mvvm это паттер для разделения кода и внешнего вида. как его уже реализуют уже другой вопрос.

Ответьте, пожалуйста, чем вам не нравится XML описание + Lua вставки? XML парсить не проблема, Lua тоже имеет нормальные исходники.

Тыщу раз уже сказал - это не решает задачу отделить дизайн УЯ от программирования и функционала прибора. Вопрос в организации взаимодействия, в архитектуре, а не в средствах - Луа или не Луа.
Вы же не предлагаете никакой организации - только инструменты.

Я спрашиваю: "Как лучше проектировать дом?", а вы отвечаете: "Тебе нужен молоток и рулетка". Это что - корректный ответ на вопрос?

Хорошо. Вот я взял Луа и ХМЛ. Все равно остаются те же самые вопросы -
1. как организовать взаимодействие между Луа и фирмварью
2. как отделить дизайн ХМЛ от Луа кода так, чтобы дизайнера с одной стороны не зажать в жесткие рамки, а с другой стороны не пускать его в программирование (на луа, бейсике, шелле, жава-скрипте - это совершенно неважно)

луа поможет не больше, чем любой другой интерпретируемый язык. т.е. напрямую никак.

Именно!

Как это не решает? Решает еще как. Пишут дизайн на XML, связывают с функционалом через Lua вставки или ЛЮБОЙ другой инструмент. А сам функционал зашейте в проц. Тот же XAML, только на коленке. И где тут интересно программирование функционала прибора?

Вы действительно не понимаете, или притворяетесь?