Здравствуйте, nvoynov, Вы писали:
N>Да кто его знает — у вас одна правда, у 1С другая — и обе они правильные Таблицы БД просто отражение модели предметной области для постоянного хранения. Я не большой дока в ORM, не пользовался и пока необходимости не возникало. ООП я знаю и конечно же использую (на уровне приложения, типа модулей, различных сервисов — почта, сортировка, поиск, ...), но привычка сначала моделировать данные еще никогда не подводила (построено пяток серьезных OLTP приложений). Функциональное моделирование и моделирование данных до сих пор успешно существуют вместе. И в предложенном фреймворке как раз такая же тема — отдельно данные и отдельно функции, которые с этими данными работают, отдельно настраиваемое представление. Не делаете ли вы тоже самое — DB-DOMAIN-UI — абсолютно тоже самое, только по другому!?
Нет. Таблицы БД никакую предметную область не отражают. Они отражают некоторую модель, причем модель структуры информации. Эта модель совершенно необязательно соответствует модели, которая в голове у пользователя.

Приведу жизненный пример: формирование заказа. Классическая задача. Решена миллион раз. При словах "формирование заказа" опытный программист корпоративного софта сразу представляет себе что-то вроде OrderDetail(OrderID foreign key referernces Orders.ID, ItemID foreign key references Items.ID, quantity decimal not null).
Следом сразу же колбасится интерфейс Master-detail; где ессно ItemID выбирается из DropDown (патамушто foreign key) и так далее.

С ростом объема прайслиста дропдаун превращается в диалог а-ля File Open, и хорошо еще, если он хотя бы запоминает последнюю позицию в каталоге.

Потом сеньор депелопер лепит фреймворк, который шлепает такой UI по структуре таблиц (плюс несложные хинты) автоматически. Он может даже научить UI поддерживать драг-н-дроп из каталога в заказ и наоборот.

Когда мы переходим в реальность оптовой выписки, оказывается, что как правило клиент делает заказ совсем не так, как программист покупает себе монитор. Он оперирует распечаткой прайс листа, напротив каждой позиции он ставит количество. И с этой распечаткой он приходит (а то и присылает по факсу) делать свой заказ.
И самым эффективным становится интерфейс, который представляет заказ не как select * from OrderDetail where OrderID=@OrderID, а как полный прайс лист с проставленными количествами по каждой позиции. Девочка "бежит" по списку со скоростью порядка 20 позиций в секунду, изредка останавливаясь, чтобы вбить количество в ту единственную ячейку, которая ей нужна. Она руками помнит количество нажатий PageDown и DownArrow, чтобы добраться до "Соус хайнц н43 200стб". Ей банально быстрее пропустить 20 ненужных позиций, чем выбрать одну нужную через наш мегаавтокомплит.

Никакой генератор UI вам это не сгенерирует. Более того, вы никогда об этом не задумаетесь, пока будете мыслить в терминах табличек и связей, а не процессов и информации.

Об этом пишет Рома. Об этом пишут авторы Inductive UI.
Да, иногда можно применять тупой механический подход. Большинство справочников мы так или иначе редактируем всё в том же гриде, до боли знакомом мне еще по Clipper'87.
Но это не потому, что природа такова. Это потому, что у нас нет ресурсов выяснить, какие именно задачи решают пользователи чаще всего.

С заказом согласен на много процентов. Сам делал несколько реализаций и первая была именно беготней по списку позиций ... набираешь часть названия и получаешь позиционирование на позиции или фильтрацию; вбиваешь количество и идешь дальше к следующей позиции ... считаются суммы; когда заказ набран он формируется дальше. Хочется отметить что на этом с самого начала настаивал заказчик ...98 год... софт работает без особых изменений по сегодняший день и никто пока не отменил принятого подхода... И реализовано было стандартным образом — торчал один и тот же фрейм, чем не генератор? Я о том и говорю

Второй софт делал немного не так — там были работы выполненные в рамках проекта. Отмечались работы и на их основе формировался счет, но это не отменяло и возможности ручного добавления/удаления работ. При этом налоги и скидки все-таки выбирались из дроп-боксов...

Следующая софтина работала с каталогом в 120000 позиций и 2000000 предложений, применялся подход похожий к 1, только вываливался уточняющий диалог. Все равно реализация механизма везде была одна и таже!

Т.е. основная мысль — критика ваша просто не принимается когда вы можете конфигурировать View часть MVC своими реализациями.

Здравствуйте, nvoynov, Вы писали:

N>Т.е. основная мысль — критика ваша просто не принимается когда вы можете конфигурировать View часть MVC своими реализациями.
Вот как раз основная мысль совершенно непонятна. Уточните мне, по каким таблицам вы собираетесь генерировать этот view?

Sinclair wrote:
> Никакой генератор UI вам это не сгенерирует. Более того, вы никогда об
> этом не задумаетесь, пока будете мыслить в терминах табличек и связей, а
> не процессов и информации.
Представь себе, как раз на прошлой неделе решили примерно такую же
задачу (точнее, несколько проще — нам не надо было количество
указывать). В виде нового плугина к генератору UI.

Какие проблемы-то? Понятно, что иногда будут требоваться нестандартные
решения, но никто же не мешает их сделать custom-но или добавить их в
генератор.

Здравствуйте, Cyberax, Вы писали:
C>Какие проблемы-то? Понятно, что иногда будут требоваться нестандартные
C>решения, но никто же не мешает их сделать custom-но или добавить их в
C>генератор.
Ну, я наверное паталогически туп. Я не понимаю, как генератор будет генерировать UI по отсутствуюшим в природе метаданным.
Пример я привел. Я понимаю, что прикрутить всё руками можно. Но я не понимаю, каким образом генератор сгенерирует всё самостоятельно.
Точнее, я представляю себе, что наверное для моего случая можно прикрутить соответствующий view, который будет чудовищным образом мерджить OrderItem с PriceListItem; но это уже получается попытка реализовать концептуальную модель взамен модели данных. На всякий случай напомню, что мы обсуждаем построение UI по модели данных. А не построение UI автоматическими генераторами в широком смысле. Под последнее вообще можно подвести всё что угодно, кроме разве что ручного размещения контролов по позициям и выполнения message pump.

Sinclair wrote:
> C>Какие проблемы-то? Понятно, что иногда будут требоваться нестандартные
> C>решения, но никто же не мешает их сделать custom-но или добавить их в
> C>генератор.
> Ну, я наверное паталогически туп. Я не понимаю, как генератор будет
> генерировать UI по отсутствуюшим в природе метаданным.
> Пример я привел. Я понимаю, что прикрутить всё /руками/ можно. Но я не
> понимаю, каким образом генератор сгенерирует всё самостоятельно.
У нас это управляется внешним XMLем — в нем описывается layout контролов
и их привязка к модели. В модели есть примерно следующее:

public class Week
{
     Set<Shift> shifts;
}

Человеку нужно этот вот Set сформировать. Во внешнем XMLе указано, что
нужно сделать список с checkbox'ами для этого Set'а. Ну генератор это и
делает.

На твой пример расширяется совершенно понятным образом.

Здравствуйте, Cyberax, Вы писали:
C>У нас это управляется внешним XMLем — в нем описывается layout контролов
C>и их привязка к модели. В модели есть примерно следующее:
C>

C>public class Week
C>{
C>     Set<Shift> shifts;
C>}
C>

C>Человеку нужно этот вот Set сформировать.
Ну то есть я надеюсь, что хоть к этому моменту стало понятно, что это нифига не storage модель? Внешний XML, модель, которую программист формирует руками... Ну и что осталось от DDL?

Здравствуйте, Sinclair, Вы писали:

C>>

C>>public class Week
C>>{
C>>     Set<Shift> shifts;
C>>}
C>>

C>>Человеку нужно этот вот Set сформировать.
S>Ну то есть я надеюсь, что хоть к этому моменту стало понятно, что это нифига не storage модель?
Почему же? Вполне storage-модель. Это классы, которые отображаются в БД с помощью Hibernate. В файлах mapping'а Hibernate'а, конечно, есть некоторая дополнительная информация по сравнению с простыми констрейнтами БД, но это все равно остается storage model.

S>Внешний XML, модель, которую программист формирует руками... Ну и что осталось от DDL?
С помощью XML даются хинты (в сколько колонок расположить, порядок элементов и т.п.).

Здравствуйте, Cyberax, Вы писали:
C>Почему же? Вполне storage-модель. Это классы, которые отображаются в БД с помощью Hibernate. В файлах mapping'а Hibernate'а, конечно, есть некоторая дополнительная информация по сравнению с простыми констрейнтами БД, но это все равно остается storage model.
Я, наверное совсем тупой. Я не понимаю, что такое Set<Shifts>, и для чего генератор проставит галочки. Для каждого шифта в сете? Откуда возьмутся UI элементы для данных, которых в сете нету?

Здравствуйте, Sinclair, Вы писали:

C>>Почему же? Вполне storage-модель. Это классы, которые отображаются в БД с помощью Hibernate. В файлах mapping'а Hibernate'а, конечно, есть некоторая дополнительная информация по сравнению с простыми констрейнтами БД, но это все равно остается storage model.
S>Я, наверное совсем тупой. Я не понимаю, что такое Set<Shifts>, и для чего генератор проставит галочки. Для каждого шифта в сете? Откуда возьмутся UI элементы для данных, которых в сете нету?
Set<Shift> — это множество результатов, которые надо выбрать. Они выбираются из множества доступных Shift'ов в текущем контексте (сложно объяснять — специфика приложения).

C>Set<Shift> — это множество результатов, которые надо выбрать. Они выбираются из множества доступных Shift'ов в текущем контексте (сложно объяснять — специфика приложения).
Ну а галочки-то напротив чего ставятся? Напротив шифтов текущего контекста, так? Ну и какая же это модель данных? текущий контекст — штука умозрительная, так же как и"прайслист с количествами". А раз умозрительная — значит описана где-то еще, не в модели данных.

Здравствуйте, Sinclair, Вы писали:

C>>Set<Shift> — это множество результатов, которые надо выбрать. Они выбираются из множества доступных Shift'ов в текущем контексте (сложно объяснять — специфика приложения).
S>Ну а галочки-то напротив чего ставятся? Напротив шифтов текущего контекста, так? Ну и какая же это модель данных? текущий контекст — штука умозрительная, так же как и"прайслист с количествами". А раз умозрительная — значит описана где-то еще, не в модели данных.
Ну не совсем умозрительная, у нас для описания контекста используется что-то типа осей в XPath, только они работают на модели данных.

Здравствуйте, Cyberax, Вы писали:
C>Ну не совсем умозрительная, у нас для описания контекста используется что-то типа осей в XPath, только они работают на модели данных.
Еще раз: в модели данных нет никаких контекстов. Контексты вы придумываете сами. Модель данных — это в чистом виде Entity-Relation. Это если данные реляционные.
То, что вы описываете в гибернейте — это уже концептуальная модель, и маппинг как раз сшивает между собой модель данных и концепт.
Я не знаю, почему вы так сопротивляетесь этому факту. Что, работа с чем-то кроме модели данных кажется неприличной?

Здравствуйте, nvoynov, Вы писали:

N>... да еще пришло в голову два слова MDA и ECO (реализация MDA от борланд) вот бы еще специалистов по этим темам услышать

Я работал не с eco, а с Bold — это мда для делфи, собственно предшественник эко.
Очень удобно. Особенно на начальном этапе проекта, когда нужно написать много кода и производительность не самое главное.