|
|
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Тема на самом деле очень интересная. И, не побоюсь этого слова, актуальная. Поэтому предлагаю: а) Признать, что вариант "генерации" UI непосредственно из метаданных немедленно превращается в вариант "хранения", как только произошла хоть какая-нибудь кастомизация сгенерированных форм, не говоря уже про добавление в формы кода в любом виде. б) Прийти к согласию, что продуктивно говорить о следующем подходе: - первичной генерации форм интерфейса пользователя на основе метаданных (в том числе с группировкой элементов интерфейса по панелям, групбоксам и табам); - кастомизации полученной болванки (обработка напильником и паяльником); - хранении полученных форм в каком-то виде и доставка их клиенту. в) Рассмотреть следующий вариант решения задачи: - Первичная генерация форм (WEB, WinForms, Delphi) на основе хранящихся в БД метаданных или (более общий случай) описаний бизнес-объектов - Доведение полученных заготовок до ума в штатной IDE - Хранение подготовленных форм в БД (это не касается WEB, по понятным причинам) в виде сборок, .dll или пакетов с загрузкой их на клиентское приложение. г) Дополнительно обсудить более сложный вопрос: внесение изменений в кастомизированные формы после изменения метаданных (или описаний бизнес-объектов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 19:28 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed ... У DevExpress 4 слоя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 19:37 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Сахават ЮсифовУ DevExpress 4 слоя. Более развернуто, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 19:40 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed Сахават ЮсифовУ DevExpress 4 слоя. Более развернуто, пожалуйста. First, the application model is generated from code. The next layer is generated when the application model is edited for a module. These changes are saved to the module's DesignedDiffs.xml file. The next layer is formed when you modify the model in a Win or Web application. These changes are saved to the corresponding Model.xml files. This is the model's final state. It is loaded when the application starts. At runtime, an end-user can also modify the model. For example, the editor can be dragged to another group. These changes are saved to the UserModel.xml file and form the application model's top layer. Multi-layer structure of the application model allows you to easily undo changes made at any layer, and return to a lower layer (lastly, you can restore the automatically generated model). To remove changes, simply remove the corresponding XML file. Of course, you can also remove only specific changes by editing XML files. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 20:04 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов First, the application model is generated from code. ... Общая идея понятна и напоминает CSS по сути. Непонятно только, из какого кода генерируется модель приложения (бизнес-объекты? иначе при чем тут метаданные?), где и в каком виде хранится логика формы (скрипты или код для проверки, вызова других форм и отчетов), и как туда подцепить самописные компоненты (например, для выбора чего-нибудь из справочника хитрым образом). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 20:24 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed Сахават Юсифов First, the application model is generated from code. ... Общая идея понятна и напоминает CSS по сути. Непонятно только, из какого кода генерируется модель приложения (бизнес-объекты? иначе при чем тут метаданные?), где и в каком виде хранится логика формы (скрипты или код для проверки, вызова других форм и отчетов), и как туда подцепить самописные компоненты (например, для выбора чего-нибудь из справочника хитрым образом). Как из какого кода? Из программного. :) Там целый фреймворк, снециально под это дело заточен. Есть определенные правила. Можно делать свои компоненты (хотя лучше чем у них врядь ли, только Гантта (хорошего, плохой есть :)) там не хватает). Вы пишите модули (class library наследует их модуль), создаете бизнес объекты, указываете всякие релейшн, агрегацию и т.д., меняете атрибуты... При каждом запуске генерируется UI. Модули показываются в NavBar, экшн в ToolBar, объекты в соответствующих конторолах, при редактировании грида создается отдельная форма и т.д. После деплоймента юзер может тоже менять аппликейшн модель, есть специальный редактор модели. Да скачайте вы его и изучайте, а еще лучше пользуйтесь. :) Линейые модули типа бухгалтерских создаеются в течении 10 минут. Аж зло берет, сколько народа в ЕРП форуме глотку рвет из-за вещей, котрые можно в течении нескольких недель сгенерировать с помощью девок. Да там еще репортинг систем с дизайнером для конечного юзера. Вобщем, конец всему. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 20:36 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов... Изучать сил нет сейчас. И вообще, я в отпуске :) Вопрос все-таки не в этом. На первом этапе собственно проектирования системы появляется структура данных. Мне бы хотелось узнать, как в этом движке реализовано создание бизнес-объектов на основе структуры БД и, соответственно, формирование интерфейса пользователя на основе той же структуры БД. И еще более интересно, как в структуре бизнес-объектов находит отражение изменение структуры этой многострадальной БД. То есть, автоматически ли у объектов появляются/исчезают атрибуты, связи и пр. при изменении таблиц, представлений, процедур и пр. Как идеал - имея на входе спроектированную базу и указав, по каким таблицам и представлениям какие бизнес-объекты необходимо генерировать, получить не только готовые business objects, но и соответствующие формы для их редактирования. Что касается возможности кастомизации внешнего вида форм (но не логики!) на клиенте, то еще не разу не видел ситуации, когда это было бы действительно необходимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 21:01 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Под самописным компонентом я имел в виду составные контролы, например, позволяющие либо выбрать вагон из списка с определенными ограничениями, либо добавить новый вагон, либо тут же на месте открыть форму и отредактировать параметры вагона. Посколько этот функционал используется во многих местах, логично объединить его весь в один контрол и втыкать везде, где необходимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 21:03 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed Вопрос все-таки не в этом. На первом этапе собственно проектирования системы появляется структура данных. Мне бы хотелось узнать, как в этом движке реализовано создание бизнес-объектов на основе структуры БД и, соответственно, формирование интерфейса пользователя на основе той же структуры БД. И еще более интересно, как в структуре бизнес-объектов находит отражение изменение структуры этой многострадальной БД. То есть, автоматически ли у объектов появляются/исчезают атрибуты, связи и пр. при изменении таблиц, представлений, процедур и пр. Как идеал - имея на входе спроектированную базу и указав, по каким таблицам и представлениям какие бизнес-объекты необходимо генерировать, получить не только готовые business objects, но и соответствующие формы для их редактирования. Есть оба варианта. Можно на основе структуры сгенерировать БО, а можно (и нужно) по коду программы сгенерировать структуру БД. Codenamed Что касается возможности кастомизации внешнего вида форм (но не логики!) на клиенте, то еще не разу не видел ситуации, когда это было бы действительно необходимо. Да вы что? Мои только и кастомизируют грид, то выкинут какие-то поля, то добавят. :) А когда можно что-то перетащить, то ОБЪЯЗАТЕЛЬНО перетащут. Они ж как дети недовольные. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 21:15 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
CodenamedПод самописным компонентом я имел в виду составные контролы, например, позволяющие либо выбрать вагон из списка с определенными ограничениями, либо добавить новый вагон, либо тут же на месте открыть форму и отредактировать параметры вагона. Посколько этот функционал используется во многих местах, логично объединить его весь в один контрол и втыкать везде, где необходимо. Есть все это, есть фильты и т.д. Выйдете на работу, посмотрите. Там изучать нечего. 1 часа хватит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 21:17 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Линейые модули типа бухгалтерских создаеются в течении 10 минут. Аж зло берет, сколько народа в ЕРП форуме глотку рвет из-за вещей, котрые можно в течении нескольких недель сгенерировать с помощью девок. Сам эту красоту только недавно заметил. Ведь еще даже релиз не вышел. Но оно только под VS.NET как я понял :( Интересно, будут ли они для Delphi делать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 21:26 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Есть оба варианта. Можно на основе структуры сгенерировать БО, а можно (и нужно) по коду программы сгенерировать структуру БД. Почему вы так считаете? :) Сахават Юсифов Да вы что? Мои только и кастомизируют грид, то выкинут какие-то поля, то добавят. :) А когда можно что-то перетащить, то ОБЪЯЗАТЕЛЬНО перетащут. Они ж как дети недовольные. :) Хм... приемосдатчик не должен кастомизировать интерфейс. Приемосдатчик должен работать. (с) неизвестный автор. :) А если серьезно, то кастомизация грида - это не есть проблема, это легко реализовать самому, без сторонних компонентов (хотя со сторонними будет, определенно, намного красивее). Здесь речь скорее идет о формах, отвечающих за редактирование атрибутов БО. Но даже и в этом случае непреодолимых трудностей не было бы, если бы формы не должны были делать много чего еще: проводить проверки (в том числе с обращением к базе), открывать другие формы (в том числе нестандартные), содержать составные компоненты интерфейса, выполнять какие-то действия в фоновом режиме и пр. Понятно, что с большинством форм таких сложностей нет. Но даже если они есть всего в 10% форм, это конкретно портит всю малину. И все-таки хотелось бы узнать на счет того, как изменения отражаются в БО и интерфейсе при изменении структуры БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 21:38 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Сахават Юсифов Линейые модули типа бухгалтерских создаеются в течении 10 минут. Аж зло берет, сколько народа в ЕРП форуме глотку рвет из-за вещей, котрые можно в течении нескольких недель сгенерировать с помощью девок. Сам эту красоту только недавно заметил. Ведь еще даже релиз не вышел. Но оно только под VS.NET как я понял :( Интересно, будут ли они для Delphi делать? Дельфи капут. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 23:48 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed Сахават Юсифов Можно на основе структуры сгенерировать БО, а можно (и нужно) по коду программы сгенерировать структуру БД. Почему вы так считаете? :) И все-таки хотелось бы узнать на счет того, как изменения отражаются в БО и интерфейсе при изменении структуры БД. Раньше никаких СУБД не было, но программы были, работали с данными и делали то же самое, что и сейчас. Просто работа была организована и регламентирована по другому во времени. Все сложности которые привнесли СУБД это сложности самих СУБД, а не данных и способов их обработки. Т.е. СУБД вторична в любом случае. Прчему я должен думать о каких-то СУБД? Я меня структуру в свой программе, а вспомогательный слой их переводит в формат СУБД, а не наоборот. Завтра СУБД может и не будет, будут другие инструменты. Эт так, лирика. Ну, там по большому все идет наоборот, меняются БО и соответственно автоматически генерируются структуры в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2007, 23:59 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов Ну, там по большому все идет наоборот, меняются БО и соответственно автоматически генерируются структуры в БД. Все-таки бизнес-объекты трудно считать первичными. При проектировании системы мы оперируем данными, которые есть в нашем распоряжении, а бизнес-объекты - всего лишь промежуточный слой для манипулирования ими. Именно построение (генерирование) интерфейса (и не только, бизнес объектов, по большому счету, тоже) на основе структуры БД - тема данного топика. К тому же, для больших баз и сложных запросов неизбежно приходится прибегать к тюнингу БД (использование индексов и статистики, частичная денормализация) и самих запросов. Крайне сложно реализовать механизм, способный при модификации структуры данных не задеть этих тонкостей. Поэтому описанное от решение DevExpress, видимо, отлично подходит для "быстрых" небольших решений "с нуля", но проектирование серьезных систем начинается с продуманной структуры БД, без чего нельзя добиться хотя бы приемлемой производительности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 00:26 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed Все-таки бизнес-объекты трудно считать первичными. При проектировании системы мы оперируем данными, которые есть в нашем распоряжении, а бизнес-объекты - всего лишь промежуточный слой для манипулирования ими. А я думаю, что главный - человек, потом объекты над которыми он трудится, потом интерфейс, через которого он трудится, а уж в самом конце форма и способ хранения объектов. Ну, девок я привел в качестве примера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 00:31 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов CodenamedПод самописным компонентом я имел в виду составные контролы, например, позволяющие либо выбрать вагон из списка с определенными ограничениями, либо добавить новый вагон, либо тут же на месте открыть форму и отредактировать параметры вагона. Посколько этот функционал используется во многих местах, логично объединить его весь в один контрол и втыкать везде, где необходимо. Есть все это, есть фильты и т.д. Выйдете на работу, посмотрите. Там изучать нечего. 1 часа хватит. Посмотреть где? Где почитать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 05:40 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Вернее так - у меня стоит неки надор компонентов DevExpress. Grid, TabSet, Page Control, MoneyEdit и прочее (всего несоклько десятков) В том числе и DataFilterDialog и т.п. Но что то я не заметил там средств для описания "бизнес-объектов", атрибутов и сущностей, а также отношений между ними и агрегации. То есть это все есть в каком пакадже? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 05:44 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed Сахават Юсифов Ну, там по большому все идет наоборот, меняются БО и соответственно автоматически генерируются структуры в БД. Все-таки бизнес-объекты трудно считать первичными. При проектировании системы мы оперируем данными, которые есть в нашем распоряжении, а бизнес-объекты - всего лишь промежуточный слой для манипулирования ими. Именно построение (генерирование) интерфейса (и не только, бизнес объектов, по большому счету, тоже) на основе структуры БД - тема данного топика. К тому же, для больших баз и сложных запросов неизбежно приходится прибегать к тюнингу БД (использование индексов и статистики, частичная денормализация) и самих запросов. Крайне сложно реализовать механизм, способный при модификации структуры данных не задеть этих тонкостей. Поэтому описанное от решение DevExpress, видимо, отлично подходит для "быстрых" небольших решений "с нуля", но проектирование серьезных систем начинается с продуманной структуры БД, без чего нельзя добиться хотя бы приемлемой производительности. Давайте попробуем танцевать от печки, т.е. от БД. 1. Строим расширенное мета-описание на базе словаря данных. В него входят интерфейсные названия объектов (краткие и полные, например, для тултипов, топик хелпа, типы доменов, описание доменов, если нужно, например, таблицы связи интерфейсных и реальных значений, идентификаторы типов контролов (именно типов, а не конкретных контролов, таким образом мы не привязаны к конкретном типу интерфейса), группировка контролов, включая панели, табы и т.д. Интересный отдельный вопрос - логическое описание типов связей между объектами. Изменение структуры БД ловим, скажем, DDL триггерами, и нотифицируем хранителя(ей) расширенного мета-описания в случае необходимости. 2. Что мы можем получить? а) Табличные представления объектов объектов с опциональными "шапками" поиска и/или фильтрации и возможностью отметки значений. б) Формы редактирования объектов, которые во многом будут похожи на вышеуказанные шапки. в) Иерархические структуры, которые могут объединять объекты разных типов, например, географические понятия, здания и помещения. г) фильтрационные шапки отчётов д) возможность создания сложных обработчиков и регистрация их через идентификаторы е) возможность кастомизации форм, которая не нарушает атомарную логическую группировку, например, запрет на отделение радио-кнопки от её группы. По моим оценкам, 80-90% интерфейса мы сможем поддержать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 09:13 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
drev Давайте попробуем танцевать от печки, т.е. от БД. 1. Строим расширенное мета-описание на базе словаря данных. В него входят интерфейсные названия объектов (краткие и полные, например, для тултипов, топик хелпа, типы доменов, описание доменов, если нужно, например, таблицы связи интерфейсных и реальных значений, идентификаторы типов контролов (именно типов, а не конкретных контролов, таким образом мы не привязаны к конкретном типу интерфейса), группировка контролов, включая панели, табы и т.д. Интересный отдельный вопрос - логическое описание типов связей между объектами. Изменение структуры БД ловим, скажем, DDL триггерами, и нотифицируем хранителя(ей) расширенного мета-описания в случае необходимости. Коллеги, а существуют какие-либо "стандартные" и/или открытые реализации такого описания? Скорее всего, это д.б. XML-схема. Частные варианты известны, но не хочется изобретать велосипед. PS. Как один из частных вариантов реализации - знаю систему которая в качестве основы использует Erwin-диаграмму, к которой добавляются стандратным образом атрибуты, схема экспортируется в XML и используется для генерации интерфейса. PPS. Спасибо за содержательные ответы. Тема давно интересует, тоже есть наработки, к сожалению, пока на них нет производственной необходимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 11:10 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
__strannik Тема давно интересует, тоже есть наработки, к сожалению, пока на них нет производственной необходимости. И никогда не будет. Еще не хватало, что бы какой-то ДБА влиял на интерфейс программы. :) А вот если у вас есть возможность, что бы клиент добавлял новые БО и логику работы с ними, тогда да, есть нужда. Ну это и есть РАД. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 11:25 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
AlexsalogВернее так - у меня стоит неки надор компонентов DevExpress. Grid, TabSet, Page Control, MoneyEdit и прочее (всего несоклько десятков) В том числе и DataFilterDialog и т.п. Но что то я не заметил там средств для описания "бизнес-объектов", атрибутов и сущностей, а также отношений между ними и агрегации. То есть это все есть в каком пакадже? Средство описания БО - это библиотека eXpress Persistent Objects (XPO). Невизуальная. То, о чем говорит Сахафат - продукт DevExpress AppFramework, сейчас в стадии RC1. Фактически, это надстройка над комплектом dXperience (полный набор компонент DevExpress), реализующая модель run-time конструирования приложения. Подходит как раз для развитых приложений, поскольку система модульная (аналог/развитие Microsoft Pattern and Practices SmartClient Software Factories). Сахават Юсифов Есть оба варианта. Можно на основе структуры сгенерировать БО, а можно (и нужно) по коду программы сгенерировать структуру БД. А тут как кому нравиться - если пляшешь от структур данных, то потом надстраиваешь БО по структурам своих данных, не хочешь сам ковыряться с БД - автогенерируй. CodenamedВсе-таки бизнес-объекты трудно считать первичными. При проектировании системы мы оперируем данными, которые есть в нашем распоряжении, а бизнес-объекты - всего лишь промежуточный слой для манипулирования ими. Именно построение (генерирование) интерфейса (и не только, бизнес объектов, по большому счету, тоже) на основе структуры БД - тема данного топика. К тому же, для больших баз и сложных запросов неизбежно приходится прибегать к тюнингу БД (использование индексов и статистики, частичная денормализация) и самих запросов. Крайне сложно реализовать механизм, способный при модификации структуры данных не задеть этих тонкостей. Поэтому описанное от решение DevExpress, видимо, отлично подходит для "быстрых" небольших решений "с нуля", но проектирование серьезных систем начинается с продуманной структуры БД, без чего нельзя добиться хотя бы приемлемой производительности. А никто не заставляет на 100% пользоваться только БО. Нужны мощные отчеты - генерируй через запросы (все-таки быстрее RDBMS в данных условиях никто не отработает). А тюнинг БД, индексы - так это не зависит от структуры данных (именно тюнинг, т.е не нормализация/денормализация, а именно подстройка параметров функционирования ядра). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 12:29 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Codenamed Именно построение (генерирование) интерфейса (и не только, бизнес объектов, по большому счету, тоже) на основе структуры БД - тема данного топика. К тому же, для больших баз и сложных запросов неизбежно приходится прибегать к тюнингу БД (использование индексов и статистики, частичная денормализация) и самих запросов. Не соглашусь с тем что это тема топика. Скорее изначально речь шла о декларативном (data-driven) описании пользовательского интерфейса. Автогенерация польз.интерфейса на основании схемы данных это далеко не единственный из подходов. Думаю найдётся много случаев когда такой подход не работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 13:48 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
Месяц назад запустил в космос систему, в которой большинство форм универсальные и автоматические. Т.к. уже устал как робот копировать гриды и формы редактирования, решил как-то совсем это исправить, опять же отдельный новый проект позволял фантазии без ущерба всему остальному :). Хотел было тоже пойти по пути генерации интерфейса, даже фастрепортовый фастскрипт смотрел (не пошло), но понял, что велосипед с квадратными колесами строить не хочется - нуна чего-то проще и лучше. Т.к. в системе больше информацию смотрят, чем правят, и нет большого количества сложных интерфейсов, решил сделать возможность там, где возможно, пользоваться универсальными формами, а где необходимо, делать сложные руками. Для списков собственно форма с гридом - метод, который отдает данные, и список полей/колонок хранится в БД. Для деталировки - опять же форма с гридом, но с двумя колонками имя-значение (кто-то раньше об этом писал, прошу прощения за тогдашнюю критику :)). Редактирование в ней же - на каждое значение поднимается формочка, соответствующая типу этого значения, в т.ч. списки. Это все также хранится в БД. Далее хранится свзяка форм друг с другом - на деталировке на закладках показаны списочные формы (клиент - на закладках счета, заказы и т.д.) Также связка действий, которые вызываются из текущей формы и могут поднимать другие формы, передавая параметры из текущей. Все это настраивается в БД. Ничего собственно не генерится - базовая форма принимает настроечные данные и только добавляет поля в гриды, точнее в датасет и грид. Афигительно удобно - т.к. нет возможности постоянного обновления ехе, то добавление большинства возможностей системы происходит автоматически, после настройки в БД, опять же если чего поправить, не надо менять, компилять и т.д. Естественно это не система, в которой юзер себе сам чего-то настраивает, но по крайней мере разработчику экономит 50% минимум времени и сил - пиши ХП и добавляй настройку формы с полями. Работает через вебсервисы - т.к. ходят извне, да еще в разные БД и сервера, то вебсервис оказался очень удобен. Собственно вот :) Правда уже и настраивать лень -- Tygra's -- Мои фотогалереи тут и тут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 15:31 |
|
||
|
Построение интерфейса приложения из БД
|
|||
|---|---|---|---|
|
#18+
tygraРаботает через вебсервисы - т.к. ходят извне, да еще в разные БД и сервера, то вебсервис оказался очень удобен. описание интерфейса хранится в какой-то центральной БД, или в каждой, в какую ходят - свое? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.08.2007, 15:55 |
|
||
|
|
start [/forum/topic.php?fid=33&msg=34700008&tid=1548962]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 154ms |
| 0 / 0 |
