[обсуждение]Динамическое создание UI (пользовательского интерфейса)
что имеется ввиду под словом "интерфейс"? UI или непосредственно interface?
Пользовательский. Те UI.
Тогда что в твоем понятии "динамически"? И про какой именно UI идеть речь? Swing, web или что-то другое?
У меня сложилось впечатление, что лучше создавать интерфейсы динамически.Что ты имеешь ввиду под "динамически"? И опиши подробнее, что за задача, в которой это нужно?
Например, мне нужно вводить данные в БД.
У меня есть N таблиц (сущностей которые я хочу заполнять.
Для построения формы ввода достаточно знать структуру данных.
И я хочу по этой структуре генерить эти формы.
Конкретно, какой UI - я считаю не принципиально - как раз у меня мб несколько генерилок - под Swing, web и что-то другое.
И я, беря на вход структуру данных и генерилку, хочу получить форму.
У меня есть N таблиц (сущностей которые я хочу заполнять.
Для построения формы ввода достаточно знать структуру данных.
И я хочу по этой структуре генерить эти формы.
Конкретно, какой UI - я считаю не принципиально - как раз у меня мб несколько генерилок - под Swing, web и что-то другое.
И я, беря на вход структуру данных и генерилку, хочу получить форму.
Еще пример.
У меня есть несколько типов пользователей, интерфейсы которых должны несколько различаться.
У меня есть описание того, у кого что должно быть (еще мб общая часть) (например в xml-е и я хочу строить интерфейс для конкретного пользователя "на лету".
У меня есть несколько типов пользователей, интерфейсы которых должны несколько различаться.
У меня есть описание того, у кого что должно быть (еще мб общая часть) (например в xml-е и я хочу строить интерфейс для конкретного пользователя "на лету".
(например в xml-е и я хочу строить интерфейс для конкретного пользователя "на лету".xslt в этом случае решает, однозначно.
В таких случаях - да, стоит. Но это получается не "чистая" генерация имхо, потому как все же есть какие-то шаблоны.
> Было бы интересно услышать, сталкивается ли кто с такой проблемой и как ее решает.
иногда генерация, иногда использование общих патернов
иногда генерация, иногда использование общих патернов
А что такое чистая генерация?
Я ведь не использую совсем готовые шаблоны - я из них сначала делаю шаблон конкретного интерфейса, а уже потом по нему интерфейс.
Я ведь не использую совсем готовые шаблоны - я из них сначала делаю шаблон конкретного интерфейса, а уже потом по нему интерфейс.
> Было бы интересно услышать, сталкивается ли кто с такой проблемой и как ее решает.А можно поподробнее?
иногда генерация, иногда использование общих патернов
Чем генеришь?
Что за шаблоны?
fg
Ну, а всякие там libglade и qt не рулят? А просто создать control'ы руками (а то лишний шаг --- генерация xml --- получается)
А что такое libglade?
А чем qt принципиально отличается от библиотек java (в данном случае, swing) и mfc?
То есть для всех возможных вариантов ты предлагаешь создавать экраны руками?
А чем qt принципиально отличается от библиотек java (в данном случае, swing) и mfc?
То есть для всех возможных вариантов ты предлагаешь создавать экраны руками?
В qt диалоги описываются в xml.
Софт такой, конечно, есть. Но проблема в том, что сгенеренные интерфейсы хуже по качеству. Взять хоть тот-же пример из баз данных - автоматически можно сгенерить несколько полей ввода (Entry но гораздо лучше все эти поля уместить в таблицу, просто приятнее выглядеть будет.
Конечно можно это делать через xsl-fo
xslt в этом случае решаетвообще-то, xslt разрабатывался только для отображения. Использование xslt для ввода данных это уже отклонение от начальных задумок разработчиков....
У w3c есть стандарт XForm, который ориентирован на создание форм. Но насколько я понимаю, большого распространения он не получил, поэтому о его качестве судить сложно...
У Microsoft есть свое решение InfoPath, я его смотрел, имхо, еще сыроватый продукт, даже с точки зрения концептуальной продуманности. Правильная интеграция InfoPath и .Net возможно будет более юзабельной.
Но это всё XML, а базы у нас реляционные, и разница в модели данных будет чувствоваться везде.
Было бы интересно услышать, сталкивается ли кто с такой проблемой и как ее решает.
Для построения формы ввода достаточно знать структуру данных.я думаю, эту проблему формулировали для себя многие.
И я хочу по этой структуре генерить эти формы.
Тот кто осуществит решение этой проблемы заработает кучу денег
.....мир станет лучше, и многие потеряют работуКонечно можно это делать через xsl-foРазве нельзя получить таким образом гуи на любом языке?
В ответ на:
xslt в этом случае решает
вообще-то, xslt разрабатывался только для отображения. Использование xslt для ввода данных это уже отклонение от начальных задумок разработчиков....
У w3c есть стандарт XForm, который ориентирован на создание форм
Но это всё XML, а базы у нас реляционные, и разница в модели данных будет чувствоваться везде.А чем xml плохо ложится на реляционные БД? Вроде даже схемы данных xml можно конвертировать в модели данных БД и наоборот...
Софт такой, конечно, есть. Но проблема в том, что сгенеренные интерфейсы хуже по качествуПонятно, что ручная работа всегда лучше по качеству.
Но произведение искусства и не требуется.
Можно пример софта?
И какие критерии качества труднодостижимы при генерации?
Взять хоть тот-же пример из баз данных - автоматически можно сгенерить несколько полей ввода (Entry но гораздо лучше все эти поля уместить в таблицу, просто приятнее выглядеть будет.А кто мешает настроить генератор так, чтобы сгенерилась таблица?
А есть тулза, позволяющая строить эти диалоги визуально?
Или как их обычно делают разработчики на qt?
Или как их обычно делают разработчики на qt?
Еще вопрос:
Есть такой термин IDL (Interface Data Languages, вроде как) - он имеет какое-нибудь отношение к вопросу создания интерфейсов?
Есть такой термин IDL (Interface Data Languages, вроде как) - он имеет какое-нибудь отношение к вопросу создания интерфейсов?
Имеет. Прямое! 
Я очень долго смотрю на тред, и не понимаю что ты хочешь.
Видишь ли, любое UI маппится на некоторый Объект Электрического Пространства, который требует от УИ некоторой базовой функциональности. Если у тебя так получается, что объекты требуют разной функциональности, то они должны предоставлять УИ сами, как пример - язык html и программа internet explorer. По языку описания html программа строит UI для объекта Сайт, при этом всё описание UI целиком предоставляет сам Сайт. Потому что разные Сайты требуют разной Базовой Функциональности.
Возвращаемся к некоторой базовой функциональности. Например, на нашем UI должна быть кнопка ОК, кнопка Кансел, и место, где можно изменять какие-то данные. Если ты попытаешься описать UI как объект (в смысле, сущность с методами, полями и коллбэками то сразу появятся очевидные ограничения на это самое место. То есть либо появляются ограничения, либо у тебя "место для данных" на самом деле оказывается просто плейсхолдером для UI предоставляемого этими самыми данными - и так далее рекурсивно.
Ок, есть ограничения, например, данные оформлены в таблицу. Или ещё как нибудь. И что? Для каждого элемента таблицы ты должен создать контрол / зарезервировать ячейку в своей таблице. При помощи какого-нибудь языка Высокого Уровня. Поскольку структура данных задана жёстко, то её можно описать при помощи xsd + xml, где xsd у тебя задаёт структу жостко (причём любым желаемым тобой способом xml - конкретные позиции контролов.
Всё.
Я не понимаю в чём проблема.
Если у тебя есть что описывать на текущем уровне иерархии UI, ты это прям там и описываешь любым подходящим способом, например явно в коде создаёшь и расставляешь контролы. Если нечего описывать, то это описание должно подниматься с более низкого уровня. Там точно так же.
Или ты хочешь универсальный способ описания вида контрола? гг, а нах такое нужно? Неуниверсальные есть - хтмл, например.
Короче, Шариков, ваши идеи космические как по масштабу, так и ...
Сформулируй для начала задачу, и если потом решение не окажется очевидным, в чём я лично сильно сомневаюсь, то можно будет подумать. А размышлять на тему "как бы универсально описывать UI" не потрудившись сформулировать хотя бы что такое UI и что оно должно делать - пустая трата времени.
Видишь ли, любое UI маппится на некоторый Объект Электрического Пространства, который требует от УИ некоторой базовой функциональности. Если у тебя так получается, что объекты требуют разной функциональности, то они должны предоставлять УИ сами, как пример - язык html и программа internet explorer. По языку описания html программа строит UI для объекта Сайт, при этом всё описание UI целиком предоставляет сам Сайт. Потому что разные Сайты требуют разной Базовой Функциональности.
Возвращаемся к некоторой базовой функциональности. Например, на нашем UI должна быть кнопка ОК, кнопка Кансел, и место, где можно изменять какие-то данные. Если ты попытаешься описать UI как объект (в смысле, сущность с методами, полями и коллбэками то сразу появятся очевидные ограничения на это самое место. То есть либо появляются ограничения, либо у тебя "место для данных" на самом деле оказывается просто плейсхолдером для UI предоставляемого этими самыми данными - и так далее рекурсивно.
Ок, есть ограничения, например, данные оформлены в таблицу. Или ещё как нибудь. И что? Для каждого элемента таблицы ты должен создать контрол / зарезервировать ячейку в своей таблице. При помощи какого-нибудь языка Высокого Уровня. Поскольку структура данных задана жёстко, то её можно описать при помощи xsd + xml, где xsd у тебя задаёт структу жостко (причём любым желаемым тобой способом xml - конкретные позиции контролов.
Всё.
Я не понимаю в чём проблема.
Если у тебя есть что описывать на текущем уровне иерархии UI, ты это прям там и описываешь любым подходящим способом, например явно в коде создаёшь и расставляешь контролы. Если нечего описывать, то это описание должно подниматься с более низкого уровня. Там точно так же.
Или ты хочешь универсальный способ описания вида контрола? гг, а нах такое нужно? Неуниверсальные есть - хтмл, например.
Короче, Шариков, ваши идеи космические как по масштабу, так и ...
Сформулируй для начала задачу, и если потом решение не окажется очевидным, в чём я лично сильно сомневаюсь, то можно будет подумать. А размышлять на тему "как бы универсально описывать UI" не потрудившись сформулировать хотя бы что такое UI и что оно должно делать - пустая трата времени.
Вот тебе и сцылочка на аналогичный случай 
Это неконструктивная ссылка 
Аргументация будет?
В IDL под интерфейсами подразумевают совсем не то, что ты, по всей вероятности, имеешь в виду.
> Есть такой термин IDL (Interface Data Languages, вроде как) - он имеет какое-нибудь отношение к вопросу создания интерфейсов?
К интерфейсам имеет прямое отношение.
К пользовательскому интерфейсу не имеет никакого отношения.
К интерфейсам имеет прямое отношение.
К пользовательскому интерфейсу не имеет никакого отношения.
> И какие критерии качества труднодостижимы при генерации?
Основная проблема - что при создании UI есть много слишком разнообразных нечетких правил.
Соответственно требуется:
1. К данным добавлять очень много декларативной информации
Пример:
меню - для того, чтобы автоматом раскидать команды - необходимо очень много знать про эти команды
2. Уметь записывать/обрабатывать нечеткие правила
пример:
желательно, чтобы на экране было не более 3-7 разнородных активных объектов на экране - другими словами - это правило записывается так:
5 - нормально, 8 - еще более менее, 15 - плохо, 50 - но разбитых на 8 групп - опять нормально
3. Уметь обрабатывать противоречия в правилах
Пример:
1. Вся информация должна быть выведена пользователю
2. На экран влазит только N-контролов
и т.д.
Все это приводит к тому, что генератор Gui - по сути своей представляет что-то среднее между экспертной системой и ИИ.
Основная проблема - что при создании UI есть много слишком разнообразных нечетких правил.
Соответственно требуется:
1. К данным добавлять очень много декларативной информации
Пример:
меню - для того, чтобы автоматом раскидать команды - необходимо очень много знать про эти команды
2. Уметь записывать/обрабатывать нечеткие правила
пример:
желательно, чтобы на экране было не более 3-7 разнородных активных объектов на экране - другими словами - это правило записывается так:
5 - нормально, 8 - еще более менее, 15 - плохо, 50 - но разбитых на 8 групп - опять нормально
3. Уметь обрабатывать противоречия в правилах
Пример:
1. Вся информация должна быть выведена пользователю
2. На экран влазит только N-контролов
и т.д.
Все это приводит к тому, что генератор Gui - по сути своей представляет что-то среднее между экспертной системой и ИИ.
> Сформулируй для начала задачу
Задача формирулируется, на первый взгляд, просто.
Есть данные, есть схема данных - которые эти данные описывает.
Необходимо максимально автоматическим образом построить GUI, который позволяет просматривать и редактировать эти данные.
В более сложных случаях, GUI также должен позволять управлять эти данными.
Задача формирулируется, на первый взгляд, просто.
Есть данные, есть схема данных - которые эти данные описывает.
Необходимо максимально автоматическим образом построить GUI, который позволяет просматривать и редактировать эти данные.
В более сложных случаях, GUI также должен позволять управлять эти данными.
А можно ссылку на описание стандарта?
А то у меня ссылки, только относящиеся к Корбе
Или он только там и есть?
А то у меня ссылки, только относящиеся к Корбе
Или он только там и есть?
> А можно ссылку на описание стандарта?
С чистым IDL-ем - напрямую, не сталкивался.
Есть MIDL - microsoft-овское расширение IDL-я. О Midl-е соответственно можно почитать в msdn-е (локально или в инете).
С чистым IDL-ем - напрямую, не сталкивался.
Есть MIDL - microsoft-овское расширение IDL-я. О Midl-е соответственно можно почитать в msdn-е (локально или в инете).
В целом IDL - не интересный, как язык.
У IDL-я основное предназначение - это обеспечить бинарную совместимость программных интерфейсов при взаимодействии программ, написанных, в том числе на разных языках.
ps
На данный момент IDL уже скорее deprecated, т.к. вместо него сейчас двигают xml.
У IDL-я основное предназначение - это обеспечить бинарную совместимость программных интерфейсов при взаимодействии программ, написанных, в том числе на разных языках.
ps
На данный момент IDL уже скорее deprecated, т.к. вместо него сейчас двигают xml.
бинарная совместимость это про СОМ
>Необходимо максимально автоматическим образом построить GUI, который позволяет просматривать и
>редактировать эти данные.
Нах?
Потому что наиболее общий случай - это один тривью + один комбобокс с забитой обработкой интов/булов/флоатов/енумов/строк. Редактируется всё что угодно, видна иерархическая структура. Для _общего_ случая _произвольных_ данных ничего удобнее человечество не придумало и не придумает.
Только это не нужно, потому что неудобно. Поэтому к данным желательно прилагать описание интерфейса. Например, в виде xsd + xml. А вот что именно в этом описании находится - тип-маппинг-позиция-размер или произвольная структура включающая в себя скрипты - дело аффтара системы, ибо ничего сложного в придумывании формата нету, а фантазия тоже вполне бесконечна. А хочешь чего-нить стандартного - бери хтмл за основу. Или как там точно называется то что позволяет делать кнопки и комбобоксы со скриптами, пох.
>редактировать эти данные.
Нах?
Потому что наиболее общий случай - это один тривью + один комбобокс с забитой обработкой интов/булов/флоатов/енумов/строк. Редактируется всё что угодно, видна иерархическая структура. Для _общего_ случая _произвольных_ данных ничего удобнее человечество не придумало и не придумает.
Только это не нужно, потому что неудобно. Поэтому к данным желательно прилагать описание интерфейса. Например, в виде xsd + xml. А вот что именно в этом описании находится - тип-маппинг-позиция-размер или произвольная структура включающая в себя скрипты - дело аффтара системы, ибо ничего сложного в придумывании формата нету, а фантазия тоже вполне бесконечна. А хочешь чего-нить стандартного - бери хтмл за основу. Или как там точно называется то что позволяет делать кнопки и комбобоксы со скриптами, пох.
Спасибо.
1. Это можно делать как по самой структуре данных или по самим данным (но редко когда ее достаточно так и получая информацию от классов/объектов логики, которая связана с этими данными;
2. Можно использовать шаблоны, компоненты и прочие готовые эл-ты интерфейса;
2,3. Можно дать пользователю возможность по подгонке интерфейса под себя (обратная связь?)
> И какие критерии качества труднодостижимы при генерации?Необязательно решать задачу сразу настолько широко:
Основная проблема - что при создании UI есть много слишком разнообразных нечетких правил.
Соответственно требуется:
...
Все это приводит к тому, что генератор Gui - по сути своей представляет что-то среднее между экспертной системой и ИИ.
1. Это можно делать как по самой структуре данных или по самим данным (но редко когда ее достаточно так и получая информацию от классов/объектов логики, которая связана с этими данными;
2. Можно использовать шаблоны, компоненты и прочие готовые эл-ты интерфейса;
2,3. Можно дать пользователю возможность по подгонке интерфейса под себя (обратная связь?)
> 2,3. Можно дать пользователю возможность по подгонке интерфейса под себя (обратная связь?)
Дай ему Visual Studio в лапы, и пусть рисует интерфейс
Дай ему Visual Studio в лапы, и пусть рисует интерфейс
> Потому что наиболее общий случай - это один тривью + один комбобокс с забитой обработкой интов/булов/флоатов/енумов/строк. Редактируется всё что угодно, видна иерархическая структура.
В общем случае, уже есть проблемы при создании даже такого представления.
Особенно если хочется поддержать групповые операции, или если данных больше 1000.
также необходимо показывать:
команды,
их выполнение.
Уметь делать undo/redo и т.д.
> Для _общего_ случая _произвольных_ данных ничего удобнее человечество не придумало и не придумает.
Еще есть грид, tree-грид в разных вариациях, есть граф. представление - схемы и т.д.
> Только это не нужно, потому что неудобно.
Корпоративные системы - где экранных форм много, а времени на разработку каждой отдельной формы надо потратить мало, как раз, обычно, используют комбинацию дерева и грида.
Дерево - обеспечивает навигацию.
Грид - отображает/редактирует данные.
В целом пользователи - довольны, что не совсем согласуется с твоим мнением, что это неудобно.
В общем случае, уже есть проблемы при создании даже такого представления.
Особенно если хочется поддержать групповые операции, или если данных больше 1000.
также необходимо показывать:
команды,
их выполнение.
Уметь делать undo/redo и т.д.
> Для _общего_ случая _произвольных_ данных ничего удобнее человечество не придумало и не придумает.
Еще есть грид, tree-грид в разных вариациях, есть граф. представление - схемы и т.д.
> Только это не нужно, потому что неудобно.
Корпоративные системы - где экранных форм много, а времени на разработку каждой отдельной формы надо потратить мало, как раз, обычно, используют комбинацию дерева и грида.
Дерево - обеспечивает навигацию.
Грид - отображает/редактирует данные.
В целом пользователи - довольны, что не совсем согласуется с твоим мнением, что это неудобно.
> Дай ему Visual Studio в лапы, и пусть рисует интерфейс
Можно обойтись без Visual Studio.
AFAIK, большая часть дизайна студии может работать и без самой студии, причем на стороне пользователя.
Можно обойтись без Visual Studio.
AFAIK, большая часть дизайна студии может работать и без самой студии, причем на стороне пользователя.
> 2,3. Можно дать пользователю возможность по подгонке интерфейса под себя (обратная связь?)
Можно, конечно, взять тот же Magic controls, наваять кучу панелек и пусть их пользователь далее сам соединяет.
Для web-а есть WebParts.
Но панельки приходится все равно программистам создавать.
Можно, конечно, тоже попытаться это отдать пользователям, но проблема в том, как доступно для пользователя организовать процедуру binding-а.
Да, у данных еще должна быть довольно четкая объектая структура - иначе там "пользователь ногу сломит" - пытаясь выяснить, что чему соответствует.
Можно, конечно, взять тот же Magic controls, наваять кучу панелек и пусть их пользователь далее сам соединяет.
Для web-а есть WebParts.
Но панельки приходится все равно программистам создавать.
Можно, конечно, тоже попытаться это отдать пользователям, но проблема в том, как доступно для пользователя организовать процедуру binding-а.
Да, у данных еще должна быть довольно четкая объектая структура - иначе там "пользователь ногу сломит" - пытаясь выяснить, что чему соответствует.
любое UI маппится на некоторый Объект Электрического Пространства, который требует от УИ некоторой базовой функциональностиЧто ты подразумеваешь под базовой функциональностью?
Это бизнеслогика?
Если у тебя так получается, что объекты требуют разной функциональности, то они должны предоставлять УИ сами, как пример - язык html и программа internet explorer. По языку описания html программа строит UI для объекта Сайт, при этом всё описание UI целиком предоставляет сам Сайт. Потому что разные Сайты требуют разной Базовой Функциональности.Не обязательно предоставлять УИ, можно предоставлять только информацию о нем.
Если ты попытаешься описать UI как объектКак раз это сейчас прекрасно осуществляется.
Взять тот же swing.
то сразу появятся очевидные ограничения на это самое место. То есть либо появляются ограничения,А кто сказал, что будет просто?
либо у тебя "место для данных" на самом деле оказывается просто плейсхолдером для UI предоставляемого этими самыми данными - и так далее рекурсивно.Чем это плохо?
Если у тебя есть что описывать на текущем уровне иерархии UI, ты это прям там и описываешь любым подходящим способом, например явно в коде создаёшь и расставляешь контролы. Если нечего описывать, то это описание должно подниматься с более низкого уровня. Там точно так же.Это все понятно. Я так писал ГУИ.
Я не понимаю в чём проблема.
Короче, Шариков, ваши идеи космические как по масштабу, так и ...Противоречивые утверждения
как бы универсально описывать UIРечь об описании шла в контексте генерации. Ведь что бы что-то сгенерить, надо знать, что.
Сформулируй для начала задачуОдна из граней этой формулировки следующая:
Существует ли визуальное средство разработки ГУИ, которое бы позволяло получать результат не в коде, а в виде некоторого описания (например, xml + библиотека визуализации таких описаний на соотв языке.
Из этого существования следовала бы возможность по крайней мере создавать шаблоны и комбинировать их при построении интерфейса.
Как вариант, по описанию должна осуществляться кодогенерация.
> Существует ли визуальное средство разработки ГУИ, которое бы позволяло получать результат не в коде, а в > виде некоторого описания (например, xml + библиотека визуализации таких описаний на соотв языке.
XAML - например.
ps
Asp.net 2.0 даже под это определение подходит.
XAML - например.
ps
Asp.net 2.0 даже под это определение подходит.
Потому что наиболее общий случай - это один тривью + один комбобокс с забитой обработкой интов/булов/флоатов/енумов/строк. Редактируется всё что угодно, видна иерархическая структура. Для _общего_ случая _произвольных_ данных ничего удобнее человечество не придумало и не придумает.Интерфейс такого контрола будет монстром
Только это не нужно, потому что неудобно.Или почему еще?
дело аффтара системы, ибо ничего сложного в придумывании формата нету, а фантазия тоже вполне бесконечнаТо ли ситуация в этой области еще не дошла до уровня промышленного стандарта, то ли многим просто нравится все каждый раз писать с нуля и ездить на таких велосипедах
Кому-то так и приходится подаваться в программисты, просто чтобы сделать так, как ему удобнее
Но панельки приходится все равно программистам создавать.В идеале таких панелек быть не должно
Да, у данных еще должна быть довольно четкая объектая структура - иначе там "пользователь ногу сломит" - пытаясь выяснить, что чему соответствует.У данных всегда должна быть четкая структура. Иначе что-то не так.
Можно, конечно, тоже попытаться это отдать пользователям, но проблема в том, как доступно для пользователя организовать процедуру binding-а.Если пофантазировать, то можно представить следующее:
Есть "голые" данные, но пользователь ничего с ними не может сделать, только просматривать.
Но у пользователя есть возможность привязки функциональности к этим данным
Он сам не пишет эту функциональность, хотя можно разрешить и такое (скриптами, например).
Он только выципляет интерфейсы (функциональность которые привязаны к этим данным, и преобразует их в ГУИ (сообщает системе, что хочет их видеть).
Добавить к этому перетаскивание, шаблоны и отслеживание пользовательских предпочтений - и может получиться очень удобная система
>Что ты подразумеваешь под базовой функциональностью?
>Это бизнеслогика?
Наличие кнопок ОК и Кансел, например. Да, можно назвать это бизнес-логикой. Но вообще речь о том, что у тебя есть некий внутренний Объект (со своими полями, методами и подобъектами) и его Пользовательский Интерфейс. Я в этом контексте на всё смотрю.
>Не обязательно предоставлять УИ, можно предоставлять только информацию о нем.
Мы говорим на немного разных языках. Я недавно понял, что C# - это очень удобный скриптовый язык. Ещё это очень удобный язык для описания данных. Поэтому я не вижу принципальной разницы между предоставлением УИ в виде кода на шарпе или в виде куска xml.
>Как раз это сейчас прекрасно осуществляется.
А я что, спорю?
>А кто сказал, что будет просто?
>Чем это плохо?
Я вообще-то не критикую ничего, а описываю как это всё должно работать. Прочитай мой пост ещё раз, осознавая что это не критика, а описание системы.
>Существует ли визуальное средство разработки ГУИ, которое бы позволяло получать результат не в
>коде, а в виде некоторого описания (например, xml + библиотека визуализации таких описаний на
>соотв языке.
Не вижу разницы между кодом и описанием. Код - это тоже прекрасное описание.
>Из этого существования следовала бы возможность по крайней мере создавать шаблоны и комбинировать
>их при построении интерфейса.
Код тоже можно комбинировать и использовать шаблоны.
>То ли ситуация в этой области еще не дошла до уровня промышленного стандарта, то ли многим просто
>нравится все каждый раз писать с нуля и ездить на таких велосипедах
Задача настолько простая, что любой всеобъемлющий стандарт будет приносить больше вреда (ограничивая фантазию аффторов) чем пользы. Потому ничего сложного в написании xsdшки и библиотечки которая по этой xsd строит и обрабатывает УИ для базы данных (к которой прилагается иерархия хмлек с описаниями) - нету. А прикладных достаточно мощных стандартов много - например, хтмл.
Короче, суммирую моё мнение:
1) чем более широкий класс данных будет поддерживать твой генератор УИ, тем менее удобные УИ будут получаться. Поэтому строить Универсальный Генератор бессмысленно.
2) Задача построения неуниверсального генератора тривиальна, поэтому пытаться запихнуть себя в рамки какого-нибудь стандарта - значит ограничить себя.
Вот.
>Это бизнеслогика?
Наличие кнопок ОК и Кансел, например. Да, можно назвать это бизнес-логикой. Но вообще речь о том, что у тебя есть некий внутренний Объект (со своими полями, методами и подобъектами) и его Пользовательский Интерфейс. Я в этом контексте на всё смотрю.
>Не обязательно предоставлять УИ, можно предоставлять только информацию о нем.
Мы говорим на немного разных языках. Я недавно понял, что C# - это очень удобный скриптовый язык. Ещё это очень удобный язык для описания данных. Поэтому я не вижу принципальной разницы между предоставлением УИ в виде кода на шарпе или в виде куска xml.
>Как раз это сейчас прекрасно осуществляется.
А я что, спорю?
>А кто сказал, что будет просто?
>Чем это плохо?
Я вообще-то не критикую ничего, а описываю как это всё должно работать. Прочитай мой пост ещё раз, осознавая что это не критика, а описание системы.
>Существует ли визуальное средство разработки ГУИ, которое бы позволяло получать результат не в
>коде, а в виде некоторого описания (например, xml + библиотека визуализации таких описаний на
>соотв языке.
Не вижу разницы между кодом и описанием. Код - это тоже прекрасное описание.
>Из этого существования следовала бы возможность по крайней мере создавать шаблоны и комбинировать
>их при построении интерфейса.
Код тоже можно комбинировать и использовать шаблоны.
>То ли ситуация в этой области еще не дошла до уровня промышленного стандарта, то ли многим просто
>нравится все каждый раз писать с нуля и ездить на таких велосипедах
Задача настолько простая, что любой всеобъемлющий стандарт будет приносить больше вреда (ограничивая фантазию аффторов) чем пользы. Потому ничего сложного в написании xsdшки и библиотечки которая по этой xsd строит и обрабатывает УИ для базы данных (к которой прилагается иерархия хмлек с описаниями) - нету. А прикладных достаточно мощных стандартов много - например, хтмл.
Короче, суммирую моё мнение:
1) чем более широкий класс данных будет поддерживать твой генератор УИ, тем менее удобные УИ будут получаться. Поэтому строить Универсальный Генератор бессмысленно.
2) Задача построения неуниверсального генератора тривиальна, поэтому пытаться запихнуть себя в рамки какого-нибудь стандарта - значит ограничить себя.
Вот.
ИМХО без модельной задачи (а лучше сразу нескольких) говорить об этом всём бессмысленно. Какие-то абстрактные "данные", которые абстрактный пользователь может "просматривать"...
А вот когда ты придумаешь парочку модельных задач, ты сразу увидишь, что "нефиг думать, трясти надо" - то есть УИ к каждой из них пишется очень быстро безо всякого генератора.
ЗЫ: Проблема высосана из пальца имхо.
А вот когда ты придумаешь парочку модельных задач, ты сразу увидишь, что "нефиг думать, трясти надо" - то есть УИ к каждой из них пишется очень быстро безо всякого генератора.
ЗЫ: Проблема высосана из пальца имхо.
Ну то есть шаблоны и настраиваемость - это добро, конечно. Но к автоматической генерации УИ вообще никакого отношения не имеет. Шаблоны и настраиваемость - это относится к Content Management Systems, к разнообразным пхп-конструкторам етс.
В принципе вся эта функциональность есть в даже в windows forms - потенциально.
Не знаю, короче. Без модельной задачи это всё выглядит попыткой объять необъятное, причём относительно этого необъятного совершенно непонятно существует ли оно вообще.
Мне это пока совершенно не нужно. Просто потому что я считаю, что грамотный код является более удобным описанием УИ чем хмлка.
В принципе вся эта функциональность есть в даже в windows forms - потенциально.
Не знаю, короче. Без модельной задачи это всё выглядит попыткой объять необъятное, причём относительно этого необъятного совершенно непонятно существует ли оно вообще.
Мне это пока совершенно не нужно. Просто потому что я считаю, что грамотный код является более удобным описанием УИ чем хмлка.
Мы говорим на немного разных языках.Я и на C# пишу, так что...
Ещё это очень удобный язык для описания данныхХотелось бы взглянуть на пример.
Я, например, его в этой роли плохо представляю - мб пример все изменит
int[] dataArray = {0, 1, 2, 3};
Как пример покатит? =)
Как пример покатит? =)
Примеры скриптов даже страшно представить после этого
> Ещё это очень удобный язык для описания данных.
Попробуй, например, описать на C# простую структуру данных (причем лучше описать, чем закодить):
'->' - один (не больше одного) ко многому
Попробуй, например, описать на C# простую структуру данных (причем лучше описать, чем закодить):
где '<->' означает много ко многому,
Фильм <-> Актер
Фильм <-> Жанр
Фильм <-> Страна
Фильм -> Файл
'->' - один (не больше одного) ко многому
class Film
{
string name;
string year;
Genre[] genres;
Actor[] actors;
Country[] countries;
// A dal'she ctor i pro4aja hernya
}
class Country
{
string name;
SortedList films; // Da, otsutstvie generics soset
}
class FilmCollection
{
SortedList films;
SortedList countries;
public Film this[string] { get; }
public Film AddFilm(string name, int year, Actor [] actors, Genre [] genres, Country [] countries); // + overloads.
}
По идее, конечно, сортедлисты сосут, и надо вместо них делать свои strongly typed collections. А еще надо сделать защиту от дурака через internal функции, заныкав конструктор Film, так чтобы получать фильмы можно было только от FilmCollection, но это уже как бы действительно код.
А так - описание структуры есть. Между прочим, легко перегоняется в xml.
Описывать содержимое конкретной коллекции фильмов тоже очень просто и приятно. Что характерно, грамотный сериалайз тоже будет автоматически засовывать всё в xml и обратно, правда, помницца, у кого-то тут были проблемы с сериализацией сложных структур, но это детали. На худой конец и ручками можно описать.
Нет, я не спорю, что данные лучше хранить в базе данных, она для этого сделана. Но наиболее удобной прокладкой между базой данных и формой (хтмлкой) ИМХО является не набор хмлек, а простенький классик на шарпе (например).
{
string name;
string year;
Genre[] genres;
Actor[] actors;
Country[] countries;
// A dal'she ctor i pro4aja hernya
}
class Country
{
string name;
SortedList films; // Da, otsutstvie generics soset
}
class FilmCollection
{
SortedList films;
SortedList countries;
public Film this[string] { get; }
public Film AddFilm(string name, int year, Actor [] actors, Genre [] genres, Country [] countries); // + overloads.
}
По идее, конечно, сортедлисты сосут, и надо вместо них делать свои strongly typed collections. А еще надо сделать защиту от дурака через internal функции, заныкав конструктор Film, так чтобы получать фильмы можно было только от FilmCollection, но это уже как бы действительно код.
А так - описание структуры есть. Между прочим, легко перегоняется в xml.
Описывать содержимое конкретной коллекции фильмов тоже очень просто и приятно. Что характерно, грамотный сериалайз тоже будет автоматически засовывать всё в xml и обратно, правда, помницца, у кого-то тут были проблемы с сериализацией сложных структур, но это детали. На худой конец и ручками можно описать.
Нет, я не спорю, что данные лучше хранить в базе данных, она для этого сделана. Но наиболее удобной прокладкой между базой данных и формой (хтмлкой) ИМХО является не набор хмлек, а простенький классик на шарпе (например).
Всё целиком мне было вбивать влом, конечно же.
Есть следующие вопросы по этому описанию:
1. У фильма может встречаться актер два раза?
Если нет, то где это написано?
2. Что происходит, если я хочу фильму назначит новую страну?
Удалить фильм из страны?
3. При удалении фильма - должны ли удаляться актеры, страны и жанры с ним связанные?
4. При удалении страны - должны ли удаляться фильмы с ней связанные?
5. Каким образом идентифицируются фильм, актер, страна, жанр?
Что происходит с идентификацией при переходе на другой язык?
6. Может ли имя фильма, актера принять нулевое или пустое значение?
7. Может ли год принимать отрицательные значения?
8. Могут ли другие части программы понять, что поле year - это именно год, и что соответсвенно с этим полем можно проводить дополнительные операции: проверка на разумность, автоматическое заполнение текущим годом, что это поле можно(и это имеет смысл) преобразовывать в DateTime?
1. У фильма может встречаться актер два раза?
Если нет, то где это написано?
2. Что происходит, если я хочу фильму назначит новую страну?
Удалить фильм из страны?
3. При удалении фильма - должны ли удаляться актеры, страны и жанры с ним связанные?
4. При удалении страны - должны ли удаляться фильмы с ней связанные?
5. Каким образом идентифицируются фильм, актер, страна, жанр?
Что происходит с идентификацией при переходе на другой язык?
6. Может ли имя фильма, актера принять нулевое или пустое значение?
7. Может ли год принимать отрицательные значения?
8. Могут ли другие части программы понять, что поле year - это именно год, и что соответсвенно с этим полем можно проводить дополнительные операции: проверка на разумность, автоматическое заполнение текущим годом, что это поле можно(и это имеет смысл) преобразовывать в DateTime?
Почти убедил, сцука =)
К сожалению я не знаю других способов задания структур данных кроме xsd+xpath (и те хуйово, если честно). Поэтому могу сравнивать только с ними. Так вот, задание таких ограничений на xpath (не всех, ибо №2 я не знаю как описать =) ) выглядит приблизительно так же как и в шарпе, то есть однохуйственно.
Хотя данные лучше все-таки хранить в формате предназначенном для хранения данных, не спорю.
(бтв когда я чё-то писал, я с удивлением обнаружил, что проверка ограничений xpath производится только в момент загрузки, потом всем вдруг становится пох. Это я чего-то не догнал, или так и надо?)
Но вообще мы не об этом. Вообще мы о том, как данные попадают на экран. ИМХО наилучший способ им это делать - через эдакий прокси-объект написаный на шарпе, или другом языке общего назначения. Если у тебя есть библиотечка, поддерживающая менеджмент "шаблонов" (в языках общего назначения эта шняга называется "наследование и полиморфизм") + стандартные функции сохранения пользовательских настроек, то ты можешь писать весьма универсальные вещи.
К сожалению я не знаю других способов задания структур данных кроме xsd+xpath (и те хуйово, если честно). Поэтому могу сравнивать только с ними. Так вот, задание таких ограничений на xpath (не всех, ибо №2 я не знаю как описать =) ) выглядит приблизительно так же как и в шарпе, то есть однохуйственно.
Хотя данные лучше все-таки хранить в формате предназначенном для хранения данных, не спорю.
(бтв когда я чё-то писал, я с удивлением обнаружил, что проверка ограничений xpath производится только в момент загрузки, потом всем вдруг становится пох. Это я чего-то не догнал, или так и надо?)
Но вообще мы не об этом. Вообще мы о том, как данные попадают на экран. ИМХО наилучший способ им это делать - через эдакий прокси-объект написаный на шарпе, или другом языке общего назначения. Если у тебя есть библиотечка, поддерживающая менеджмент "шаблонов" (в языках общего назначения эта шняга называется "наследование и полиморфизм") + стандартные функции сохранения пользовательских настроек, то ты можешь писать весьма универсальные вещи.
int[] dataArray = {0, 1, 2, 3};Не покатит
Как пример покатит? =)
Такая запись уж всяко лучше:
{0, 1, 2, 3} 1. Ты описал не все (то есть затраты по реализации такого простого задания оказались достаточно большими )
2. Попробуй сделать на основе твоего кода сами данные (хотя бы по экземпляру каждого типа)
Почему не просто Array?
)2. Попробуй сделать на основе твоего кода сами данные (хотя бы по экземпляру каждого типа)
А так - описание структуры есть. Между прочим, легко перегоняется в xml.Как, если не секрет?
SortedListИз каких соображений ты заложился именно на него?
Почему не просто Array?
Но вообще мы не об этом. Вообще мы о том, как данные попадают на экран. ИМХО наилучший способ им это делать - через эдакий прокси-объект написаный на шарпе, или другом языке общего назначения. Если у тебя есть библиотечка, поддерживающая менеджмент "шаблонов" (в языках общего назначения эта шняга называется "наследование и полиморфизм") + стандартные функции сохранения пользовательских настроек, то ты можешь писать весьма универсальные вещи.А можно поподробнее про:
1. Что за
прокси-объект?
2. Что за
менеджмент "шаблонов", и причем тут
наследование и полиморфизм?
3. Что из себя представляют эти сохраненные настройки:
стандартные функции сохранения пользовательских настроек?
Я как раз и придумывал, и писал.
Так что это все не на пустом месте.
Ладно, буду думать дальше
Так что это все не на пустом месте.
Ладно, буду думать дальше
Оставить комментарий
durka82
У меня сложилось впечатление, что лучше создавать интерфейсы динамически.Однако на практике сталкиваться с таким подходом практически не приходится - как правило, интерфейс прописывается прямо в коде (взять тот же JBuilder).
Конечно можно это делать через xsl-fo, но софта, который бы позволял строить такие интерфейсы, мне не попадалось.
Было бы интересно услышать, сталкивается ли кто с такой проблемой и как ее решает.