|
|
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Покритикуйте. Back-end, ессно. Ну, хотя бы взлетит - не взлетит. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 14:21 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Это даже не нулевое, это минус тысячное приближение. Высасывать такие "генераторы" из пальца, по моему, дело абсолютно бесполезное и бесперспективное. Если бы у вас было за плечами создание конкретных прикладных систем и вы бы облегчали свой труд - замена программирование конфигурированием - тогда был бы шанс повторить путь искры или випроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 14:27 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-Л, Если хотя бы 20% функционала будет определяться таким образом, я сочту вложение сил в эту систему оправданным. Никто же не мешает сделать тип "пункт меню произвольного класса без предварительного описания" и фигачить в нем какой угодно код для отображения чего и как угодно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 14:43 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Собственно, описание и сделано минималистичным для того, чтобы - можно было создать наследников для конкретных форм и в них прописать необходимое дополнительное поведение - не создавать соблазна раздувать систему декларации вплоть до попиксельного описания ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 14:50 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Из вашего скрипта просматриватеся только меню и простой плоский грид с данными. Это, простите, совсем уж убого. Вы б начали с общей концепции дизайна интерфейса. Какие формы визуального отображения сложно устроенных данных вы предполагаете ? Могут ли они контейнироваться и как ? Как взаимодействуют друг с другом ? Без ответов на эти вопросы ваши структуры данных будут висеть в сферическом вакууме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 15:04 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ShrПокритикуйте. Back-end, ессно. Ну, хотя бы взлетит - не взлетит. не взлетит. Шансов просто нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 15:59 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Видимо, я совсем неточно выразился. Я не предполагал полного описания интерфейса и построения его исключительно на данных из базы (этой схемы). Скорее, это возможность для быстрого создания простого, но функционально достаточного интерфейса типа показать/отредактировать плоский справочник с возможностью его дальнейшей доработки в коде клиента. Вот вводные: - Вся логика в базе, в процедурах, включая запросы для показа данных - Клиент - сейчас толстый на delphi - Есть набор базовых форм и классов (грид, редактор обьекта, вызов процедуры) со стандартной функциональносью - Для каждой формы (реализации пункта меню) на данный момент есть наследник от стандартного класса, в коде которого и описано все поведение Хочется повысить уровень абстракции: - При создании нового режима описывать базовую функциональность в декларативном стиле для самых простых случаев (показ данных, процедуры, редактирование объектов). Желательно для процентов 30 тупых справочников не писать кода - На этой же платформе описывать тот же интерфейс для реализации на внутреннем портале на php - Для случаев посложнее все так же наследуемся и дописываем что надо в коде клиента Далее, что касается сложно устроенных данных и агрегирования элементов интерфейса - тут, похоже, пока полный провал. Надо дальше думать. В текущей схеме есть только: - ввод параметров процедуры - вывод датасета - связь между ними В принципе, этого достаточно для блочной постройки интерфейса: - собственно грид как результат вызова процедуры (ввод параметров) - редактор со встроенным child-гридом - мастер-деталь - отчет или процедура, вызываемый на основе текущей записи грида В схеме данных надо только выделить блоки, более строго сформулировать интерфейсы взаимодействия и добавить граф связей между блоками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 17:42 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Вот то-то и оно, что думать надо. У меня, как и многих форумчан есть собственный велосипедик, везущий на себе ВСЕ тяготы презентационного слоя приложения. Для оживления данных во всех формах, открытия и переходах между формами с сохранением контекста, поиска и фильтрации данных кода не нужно ни одной строки - все за счет настройки. Обошлось это удовольствие в пару-тройку дюжин таблиц. Но при этом есть определенная концепция интерфейса, в рамках которой надо находится для пользования этой способностью. Из дома смогу приложить принтскрин схемы данных и рабочего окна системы. Мой более продвинутый коллега сделал идеологически такой же механизм на дот нете. Более красивый, мощный и удобный. Не знаю только, захочет ли он поучаствовать в этой ветке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 17:52 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Нет, всю настройку в таблицы я класть не хочу. Тогда теряется возможность еще более тонкой настройки вроде связей между отдельными контролами либо в генератор интерфейса надо запихивать чуть ли ни каждую заказанную фичу (а у заказчиков богатая фантазия), что трудоемко, сильно засоряет декларации всякой мелочью, усложняет систему и её поддержку - в общем, не факт что в итоге оправдано. Короче, тут нужна золотая середина, и слишком большими шагами в её поисках я двигаться не буду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 18:08 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Если система предназначена только редактирования "тупых" справочников, то может и взлетит, так как , что либо сложнее с помощью такой системы вряд ли удастся построить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 19:59 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ShrНет, всю настройку в таблицы я класть не хочу. Тогда теряется возможность еще более тонкой настройки вроде связей между отдельными контролами либо в генератор интерфейса надо запихивать чуть ли ни каждую заказанную фичу (а у заказчиков богатая фантазия), что трудоемко, сильно засоряет декларации всякой мелочью, усложняет систему и её поддержку - в общем, не факт что в итоге оправдано. Короче, тут нужна золотая середина, и слишком большими шагами в её поисках я двигаться не буду. На мой взгляд вы сузили постановку задчи до недопустимо ничтожной величины. Смысла развивать топик в таком направлении я не вижу. Для практических целей такой "интерфейс" не тянет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 20:13 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-Л... Из дома смогу приложить принтскрин схемы данных и рабочего окна системы. Мой более продвинутый коллега сделал идеологически такой же механизм на дот нете. Более красивый, мощный и удобный. Не знаю только, захочет ли он поучаствовать в этой ветке.l!! даже, если ТС не откликнется на это - не забудьте !!! думаю - я не одинок в этой просьбе ТС - сорри вау ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2013, 22:47 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Программист-ЛюбительДля практических целей такой "интерфейс" не тянет.Он не тянул бы в случае коробочного решения, которое невозможно (ну, почти :) доработать ручками после выпуска. Мне не нужен путь искры, у меня не тот случай. В моем случае (внутрикорпоративная система) очень даже тянет, потому как расширяется в любую нужную сторону непосредственно в коде клиента. Еще раз, ожидания простые - есть 20-30% форм будут создаваться без написания кода клиента - мне этого будет достаточно. Тем более что в реализации по умолчанию будет и поиск и сортировка и фильтры и группировка и экспорт в 2-3 формата, и связи между отдельными наборами данных. Для чуть более чем плоских отчетов - понадобится дополнительное описание, конечно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2013, 04:50 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Попробую описать еще разок. Если представить шкалу развития автоматизации gui как: 1 - создание каждой формы с 0 10 - генерация gui полностью на основании описания, включая дизайнер непосредственно в приложении и скрипты как обработчики событий (искра) то я хочу перейти с 3 (есть набор базовых классов и форм) на 4 (структура интерфейса описана в базе, некоторая часть его отображается без кода вообще) примерно стадию, дальше мне пока не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2013, 05:07 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
дП-Л... Из дома смогу приложить принтскрин схемы данных и рабочего окна системы. Мой более продвинутый коллега сделал идеологически такой же механизм на дот нете. Более красивый, мощный и удобный. Не знаю только, захочет ли он поучаствовать в этой ветке.l!! даже, если ТС не откликнется на это - не забудьте !!! думаю - я не одинок в этой просьбе ТС - сорри вау Теперь смогу только сегодня вечером... В качестве компенсации пока расскажу/покажу на пальцах. Прикладные формы трех типов. Форма-карточка. Имеет - заголовок, в котором в сжатом виде выводится описание объекта (типа склееные номер, наименования), - (опционально) область главных данных - небольшое количество наиболее важных полей. - (опционально) набор вкладок. На каждой вкладке находится набор полей россыпью или вложенные таблицы детальных для текущего объекта данных (гриды). Вложенные таблицы имеют над собой (опционально) область “управляющих контролов” – комбобоксы для фильтрации, сортировки, строку ввода образца для мгновенного поиска. Имеется возможность встраивать в форму-карточку "стандартные вкладки" - один сгенерированый документ (ворд) определенного типа по данным текущей записи - набор сгенерированных документов разных типов по данным текущей записи - единственный вложенный документ (файл любого типа – тифф, пдф, …) - набор вложенных документов (файлов любого типа) Формирование документов ворд по данным бизнес-сущности настраивается. Есть всякие примочки для получения безукоризненных документов типа склонения ФИО в разных падежах, обращения г-н/г-жа, всякие суммы/проценты прописью и т.п. Форма-таблица. Имеет одну или несколько зон, на каждой зоне - (опционально) область “управляющих контролов” – комбобоксы для фильтрации, сортировки, строку ввода образца для мгновенного поиска. - (опционально) вложенную таблицу данных в табличном виде (грид). Гриды разных зон могут (и, как правило чаще всего так и есть) связываться друг с другом как мастер-детальные. Форма-структура. Является неким аналогом проводника с деревом объектов в левой части и карточкой текущего узла в правой части. Для корневого уровня в правой части чаще всего выводится грид самых верхних объектов. При выборе какого-либо узла в левой части в правой части выводится форма-карточка именно этого объекта. Т.е. одна и та же форма-карточка объекта обычно используется дважды: как самостоятельная карточка и как правая часть в форме-структуре. Формы-структуры оказались самыми удобными и наглядными для работы со сложными данными. Любой узел можно открыть в виде самостоятельной карточки. Из форм-таблиц текущая запись также практически всегда открывается как новая форма-карточка. Можно встроить карточку в форму-структуру: в верхней половине – список объектов, в нижней – карточка текущего объекта. Можно из текущей записи грида открывать разные карточки объектов, задействованных в данном гриде. Все команды открытия карточек тоже конфигурируются. Из грида можно выгружать отчеты в эксель в разных форматах, плоские и ОЛАП. Выгрузка отчетов, разумеется, тоже настраивается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2013, 09:30 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Выполняю просьбу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2013, 21:04 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Форма-конструктор прикладных форм. В ней открыта как раз она сама, как объект настройки/конфигурирования. Так сказать, ассемблер, написанный на ассемблере. Вкладок много, на каждой задаются данные по какому-либо аспекту конфигурирования. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.01.2013, 21:34 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-ЛВы б начали с общей концепции дизайна интерфейса. Какие формы визуального отображения сложно устроенных данных вы предполагаете ? Могут ли они контейнироваться и как ? Как взаимодействуют друг с другом ? Пора, пожалуй. Формы отображения (блоки интерфейса) бывают двух видов - отображение процедуры и формы. Процедура - это фильтр (набор входных параметров) + грид (возможно дерево), если процедура возвращает курсор (набор данных) либо ввод параметров для её вызова. Форма - это контейнер из блоков. Все блоки в форме привязаны к панелям, для задания вида отображения в виде иерархии. Взаимодействие между блоками идет тремя способами. Первый - это связи между блоками в форме (так реализуется мастер-деталь гриды, выбор значений параметров из грида и т.д). Второй - это передача параметров (возможно в т.ч. и полей курсора) блока в другой вызываемый блок (т.н. действия в блоке). Вызов возможен по кнопке на панели либо по двойному щелчку в гриде, если блок - процедура с курсором. Третий - ссылки из редактируемых параметров (выбор значений из справочников), тоже с возможной передачей параметров из текущего блока (или любого блока формы) в курсор. Каждому параметру блока можно назначить отдельный вид редактора, если редактора по умолчанию не достаточно. Каждому блоку можно указать нестандартный класс для его отображения, для его создания можно унаследоваться от стандартного и внести необходимые изменения. Написаны процедуры для автоматической генерации интерфейса (включая код процедур редактирования и выборки) для редактирования таблицы, для отображения отдельной процедуры. Пример дополнения блока (форма авторизации): Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. Вид формы - редактора формы прикладываю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.10.2013, 11:03 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Shr, добрый день! Мне кажется вы не с того конца начали - вы начали с окончания, а нужно с начала. а началом является как правило БД - вот от ее структуры и надо плясать! Для БД нужно создать мета-надстройку, которая вам и позволит создавать/конфигурировать любой интерфей любой интерфейс тем более у вас есть коллеги-динозавры в этой области - www.arbinada.com - там ребята тоже на Делфи свои первые проекты писали, но они начинали с начала - с БД! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 09:23 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
spShr, добрый день! Мне кажется вы не с того конца начали - вы начали с окончания, а нужно с начала. а началом является как правило БД - вот от ее структуры и надо плясать! Для БД нужно создать мета-надстройку, которая вам и позволит создавать/конфигурировать любой интерфей любой интерфейс тем более у вас есть коллеги-динозавры в этой области - www.arbinada.com - там ребята тоже на Делфи свои первые проекты писали, но они начинали с начала - с БД! Где начало а где конец - вопрос дискуссионный. В реляционной структуре таблиц данные лежат в удобной для восприятия конечному пользовталею форме только в простейших случаях - тестовые и учебные проекты. Как только в БД моделируется реальная практика жизни, модели резко усложняются и для расщепление бизнес-понятий на реляционные таблицы выполняется так, чтобы это правильно и логично для структуры данных, для программиста, но не для пользователя. Поэтому при реализации интерфейса разработчику нужно потратить много сил, чтобы обеспечить переход от реляционной структуры таблиц к визуальной форме, которая наглядна и удобна с точки зрения бизнеса. Для этого конструкторы/конфигураторы/построители форм должны иметь развитые средства, позволять на ходу менять визуальное представления данных (скрывать/высвечивать панели и вкладки, менять одну панель на другую, менять источники комбобоксов и т.п.). Т.е. в этом случае может иметь смысл идти именно от интерфейса, задавая для каждого его элемента биндинг на тот или иной источник данных из базы. Причем у этого биндинга должно быть много изощренных опций. Поэтому когда я давно делал свой инструментарий я использовал такую парадигму. Моделирование структуры данных (таблицы, запросы, ф-ии, процедуры) в серверной части ведутся средствами сервера. Автоматических сборщиков запросов по модели нет. Все лапками. Построение интерфейса тоже ведется средствами клиента. Тоже без автоматических построителей форм по опсианию таблиц или модели данных. А в конфигураторе форм задается отображение данных в элементы интерфейса, правила поведения интерфейса. Т.е. форма делается как пустышка, но после настройки начинает жить, обеспечивая все функции презентации данных (включая открытие новых форм, переходы по связанным формам, сортировки, фильтры, загрузку нужных данных на вкладки, генерацию документов в ворде, привязку сканов первички, выгрузку отчетов в эксель и т.п.) Это очевидно, не лучший путь, было сделано именно так по нескольким причинам: недостаток ресурсов - нужно было сделать быстро, уже имевшаяся система (1000+ форм) должна была быть перенесена на новый инструментарий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 10:36 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
spМне кажется вы не с того конца началиВы, кажется, чего-то не поняли. "Процедура" и "курсор" - это процедуры именно в БД, на psql или pl/sql - на данный момент поддерживаются Firebird и Oracle. Т.е. сначала создаем структуру БД, потом формируем процедуры для редактирования и показа данных (простые можно сгенерировать), потом конфигурируем интерфейс для компоновки вида и установки связей между вызовами процедур БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 10:39 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-Л, Shr , Чего там сложного - имея описания таблиц, связей, процедур, индексов - на основании этих данных уже можно автоматически генерить простые вью, которые на клиенте в соответствующем фреймворке MV* уже будут отреендерены. Для кастомизации форм достаточно лишь незначительных изменений Ничего особенно сложного тут нет - нужно время просто привести все это до кучи в мозгу сесть и написать) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:15 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
статьи про первые попытки автоматически генерить интерфейсы CRUD были еще лет 7 назад на просторах вражеского инета, да и сейчас я думаю статей полно уже и на наших просторах - поищите ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:17 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ТС, можете показать принтскрины конечных пользовательских форм и на пальцах пояснить как они были сконфигурированы (настроены) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:17 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
да, и обязательно! почитайте статьи на том сайте что я ранее указал, обязательно - очень помогает просветлению) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:19 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
spП-Л, Shr , Чего там сложного - имея описания таблиц, связей, процедур, индексов - на основании этих данных уже можно автоматически генерить простые вью, которые на клиенте в соответствующем фреймворке MV* уже будут отреендерены. Для кастомизации форм достаточно лишь незначительных изменений Ничего особенно сложного тут нет - нужно время просто привести все это до кучи в мозгу сесть и написать) Категорически не согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:20 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-Л, а вы и не соглашайтесь! прочтите сначала что люди до вас поизобретали, а потом можно и окончательно не соглашаться :) Я думаю тут Vipros мог бы вам оппонировать - у него давно свой фреймворк разработан именно на метамоделях - там весь интерфейс генерируется автоматически на основе метаописания базы данных + некоторые параметры настройки - поищите юзера такого у него в постах полно сложных форм в картинках из его фреймворка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 11:53 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Метаописания Випроса - это как раз та очень существенная информация, которая может держать реальные сложные модели, используемые на практике. Я против вашего тезиса, что разработать подобное можно легко и быстро. Я против вашего тезиса, что по реляционной БД, используя стандартные словари реляционых СУБД (типа INFORMATION_SCHEMA.*) можно автоматически построить интерфейс, годный для практического применения. Это может сработать только на простых, учебных проектах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 12:05 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
spимея описания таблиц, связей, процедур, индексов - на основании этих данных уже можно автоматически генерить простые вью, которые на клиенте в соответствующем фреймворке MV* уже будут отреендерены. Для кастомизации форм достаточно лишь незначительных измененийС таким подходом получается интерфейс, один в один отображающий физическую модель представления данных. Для работы пользователей он непригоден. Точнее, пригоден только для заполнения простых справочников. П-ЛТС, можете показать принтскрины конечных пользовательских форм и на пальцах пояснить как они были сконфигурированы (настроены) Скрин прикладываю. Вкладка "Цели департамента". Конфигурация - форма, на ней одна панель с направлением вывода "сверху вниз". На панели два блока с курсорами. У первой описаны параметры процедуры (они выводятся под иконками действий) и включена группировка в гриде (локальная) по двум полям. Второй - связан с первым (входные параметры взяты из входных параметров первого), и в нем включен вид "вертикальное отображение". Иконки редактирования и кнопки с текстом - вызовы других блоков с передачей параметров из текущего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 12:17 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ТС, схема формы понятна. Рендеринг положения и размера контролов автоматический ? Как она конфигурируется ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 12:26 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Контролы для ввода фильтров - включено направлено отображения "горизонтальное", ширина одного поля ввода задается шириной фрейма его редактора. Высота панели для параметров фиксированная, для одной строки (условно). Если будет задано "вертикальное", то контролы расширяются до ширины ParentWindows, высота определяется фреймом (видно в верхней части редактирования формы). Расположение гридов (блоков) - задано направление "сверху вниз". Между гридами - сплиттер, двигается пользователем, сохраняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:09 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Shr, Ширина котнтролов для фильтрации разная. Если их будет много, как они размещаются на панели ? Листбоксы на несколько строчек возможны ? Вечером из дома приложу несколько своих принтскринов для обсуждения некоторых вопросов. Считаю, что у вас логичный подход и хорошая разработка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 13:31 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-Л, я не писал что можно использовать существующую информацию в базе - я писал о создании мета надстройки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:13 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-ЛШирина котнтролов для фильтрации разная. Если их будет много, как они размещаются на панели ? Листбоксы на несколько строчек возможны ? Сейчас - тупо не влезают по ширине. Да, листбоксы возможны, но в горизонтальном расположении будут ограничены по высоте стандартом. В принципе, каждый контрол находится в отдельном фрейме с заданным минимальным размером, можно их перемещать на след. строчку при недостаточной ширине окна. Также можно сделать вертикальное расположение и разместить панель фильтрации слева от грида. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:14 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Shr, ну и что тут такого невозможного? Реализуете в БД систему раздачи прав на все объекты БД - таблицы, операции с ними. Реализуете настройку меню как у вас в левой части и если есть необходимость - настройку рабочего стола! Все это при наличии метамодели легко реализуется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:17 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
sp, Никто не говорит про невозможность. Говорят о том, что реляционная структура данных не соответствует требуемому виду интерфейса пользователя. Поэтому "незначительными изменениями" отображения одного на другое добиться не получится. В том же випросе, насколько я понял, для этого выделяется подмножество всех связей модели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:22 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Shr, ну у вас куча противоречий и подозрений потому что вы упорно не хотите почитать то что я вам предлагал :) Думаю что после прочтения развивающих статей у вас бы не осталось проблемных вопросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:24 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
во ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:53 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ViPRos, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:54 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ViPRos, ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 15:54 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Пара соображений, которыми хочу поделиться на базе опыта разработки и использования конфигуратора прикладных форм. Надо иметь возможность биндить визуальные элементы (формы, панели, гриды) на сложные источники данных - запросы, табличные функции, процедуры. При этом можно встроить в источники данных разграничения по ролям. Такое разделение может, например, быть реализовано через динамическую склейку секции WHERE sql инструкции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 22:52 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Ограничения доступа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 22:55 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
При отображении сложных данных, имеющих определенную внутреннюю структуру, очень полезно использовать соответствующий контрол - тривью, аутлинер, т.п. Пример: очень многие системы хранят в каталоге организаций отношение парент-чаилд (дочерняя/зависимая фирма, холдинг и входящие в него компании и т.п.). Среди учетных систем финансового толка мне пока не попадались такие, где эта информация отображалась наглядно в виде дерева. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:01 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Самая типичная форма - табличного типа. Выглядеть она может очень по-разному: на ней могут быть расположена всевозможные контролы, управляющие представлением данных и собственно грид, в котором выводится массив данных. Обязательно должен быть "мгновенный поиск". По мере набора текста в наборе данных должна позиционироваться запись, содержащая данный текст. Выглядит элементарно, но очень эффективно при поиске информации. Для этого же образца должна быть не менее мгновенная фильтрация набора. Что касается фильтров. Формально, если в наборе есть поля из справочников, программистам очень просто сделать выбор по справочникам. Можно добавить пукт <Все> к перечислению из справочника. Но при практической работе фильты в понятиях бизнес-терминов обычно охватывают несколько полей, или вообще представляют собой сложные выражения для секции WHERE. Я считаю что такие и нужно иметь возможность конфигурировать для табличной формы. Как простейший частный случай перекрывают возможности простого фильтра - перечисления из справочника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:24 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Пример настройки фильтра Код: sql 1. 2. 3. 4. 5. 6. 7. При выполнении этого кода получается набор данных для заполнения комбо (фильтра) на табличной форме: IDВыводится в фильтреДля сортировкиУсловие WHERE-2 <Все записи> -2 1=1-1 Только базовые -1 iUnitID_Base IS NULL1 Производные от кг. (килограмм) 400 iUnitID_Base={LIST}2 Производные от м. (метр) 100 iUnitID_Base={LIST}3 Производные от м2 (метр квадратный) 200 iUnitID_Base={LIST}5 Производные от шт. (штук) 1 iUnitID_Base={LIST}9 Производные от м3 (метр кубический) 300 iUnitID_Base={LIST} При выборе в фильтре условие WHERE добавляется к источнку данных формы. Для Только базовые получается: Код: sql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:37 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Еще хотел бы рассказать о стандартных субформах, выполняющих типовые прикладные задачи, которые могут потребоваться в любой предметной области. Может быть завтра вечером сделаю еще несколько снимков экранов и постараюсь объяснить "на пальцах." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:40 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Забыл написать, на форме настройки списка фильтрации видно, что для разных ролей можно задавать разные условия фильтрации. Это тоже бывает нужно при разделении доступа (раз наборы данных для разных ролей разные, то и условия отбора для них тоже могут потребоваться разные). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:44 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель, ты эти СКЛ от руки что ли пишешь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:46 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Программист-ЛюбительЗабыл написать, на форме настройки списка фильтрации видно, что для разных ролей можно задавать разные условия фильтрации. Это тоже бывает нужно при разделении доступа (раз наборы данных для разных ролей разные, то и условия отбора для них тоже могут потребоваться разные). и тут появляется задача и о раны значениях полей по умоляанию ля разных ролей, что нетривиально (сами фильтры то тривально генерятся и хранятся) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:48 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Я же говорю: мой "конфигуратор" соединяет серверную скуэльную часть с клиентской аксесовской. Каждая делается в своей среде. Т.е. фильтры пишу и отлаживаю руками в студии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:50 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ViPRosПрограммист-ЛюбительЗабыл написать, на форме настройки списка фильтрации видно, что для разных ролей можно задавать разные условия фильтрации. Это тоже бывает нужно при разделении доступа (раз наборы данных для разных ролей разные, то и условия отбора для них тоже могут потребоваться разные). и тут появляется задача и о раны значениях полей по умоляанию ля разных ролей, что нетривиально (сами фильтры то тривально генерятся и хранятся) Я сумел нетривиально через механизм подстановки (типа как в препроцессоре) логику формирования условий накрутить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:53 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель, фильтры то легко писать (хотя зачем их вручную, пользователь ведь не знает синаксис СКЛ) а вот смарт лукап посложнее, когда список выбора (домен) значения поля вычисляется автоматически из семантики связей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:54 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель, я ж говорю - условие ерунда, а вот по умочанию в соответствии с условием заполнять обусловленные поля - не так просто ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2013, 23:55 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Честно говоря эта проблема была не самая горячая и, соответсвенно я ее и не решал. Точнее решал простым кодингом там, где это было необходимо (в каждой конкретной форме). Обычно заполнение "смарткомбо" идет рука об руку с общей кустомной логикой контроля ввода данных. Для важных и/но сложных объектов - договор, операция по договору, лимит и т.п. у меня были сделаны мастера (визарды) с постепенным заполнением данных в зависимости от уже введенного на предыдущих шагах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2013, 08:53 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-Л, я понимаю, ты просто облегчаешь собственную жисть, нет цели сделать фреймворк полноценный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2013, 11:51 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
смарт лукапы очень интересная весч ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2013, 23:37 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
не лучше будет как-нибудь xaml разметку динамически из той же бд подгружать? или целые EXEшники из бд тягать и запускать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2013, 13:05 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Посмотрите в сторону Oracle APEX - очень грамотно все сделано. Можно много почерпнуть для своих поделок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2013, 13:40 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Программист-ЛюбительПри этом можно встроить в источники данных разграничения по ролям.У меня в клиенте sql нет вообще, все обращение через процедуры. Соответственно, если нужны будут разные where для разных ролей - буду в ХП либо писать if и возвращать разные курсоры, либо склеивать запрос динамически, либо использовать or в одном запросе - в зависимости от требований производительности. Программист-ЛюбительПри отображении сложных данных, имеющих определенную внутреннюю структуру, очень полезно использовать соответствующий контрол - тривью, аутлинер, т.п. Пример: очень многие системы хранят в каталоге организаций отношение парент-чаилд (дочерняя/зависимая фирма, холдинг и входящие в него компании и т.п.). Среди учетных систем финансового толка мне пока не попадались такие, где эта информация отображалась наглядно в виде дерева.TcxTreeList - и колонки, и дерево. Программист-ЛюбительОбязательно должен быть "мгновенный поиск". По мере набора текста в наборе данных должна позиционироваться запись, содержащая данный текст. Выглядит элементарно, но очень эффективно при поиске информации. Для этого же образца должна быть не менее мгновенная фильтрация набора.Это есть, прикладываю скрин. Поиск в отдельной строке - на самом деле фильтрация на клиенте, в лукап-комбо работает такая же (строится такое же выражение по отдельным словам). В самом гриде уже в каждой колонке есть инкрементальный поиск. Программист-ЛюбительЧто касается фильтров. Формально, если в наборе есть поля из справочников, программистам очень просто сделать выбор по справочникам. Можно добавить пукт <Все> к перечислению из справочника. Но при практической работе фильты в понятиях бизнес-терминов обычно охватывают несколько полей, или вообще представляют собой сложные выражения для секции WHERE. Я считаю что такие и нужно иметь возможность конфигурировать для табличной формы. Как простейший частный случай перекрывают возможности простого фильтра - перечисления из справочника.Да, это интересный способ, приму на вооружение. Я обычно делал для такого отдельные параметры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2013, 15:56 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
SlalomПосмотрите в сторону Oracle APEX - очень грамотно все сделано. Можно много почерпнуть для своих поделок.Спасибо, посмотрю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2013, 15:57 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
ShrДа, это интересный способ, приму на вооружение. Я обычно делал для такого отдельные параметры.У меня очень похожий визуальный построитель SQL WHERE условий, только используется он в "проверочных отчетах" - для контроля качества данных. К условиям для фильтров я себе такую штуку прикручивать не стал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2013, 16:54 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
П-ЛУ меня очень похожий визуальный построитель SQL WHERE условий, только используется он в "проверочных отчетах" - для контроля качества данных. К условиям для фильтров я себе такую штуку прикручивать не стал.Нет, это работает в обратном направлении. Пользователь набирает в строке поиска куски слов, я (в коде) формирую простое условие, грид по нему фильтрует. То, что показано на скрине - редактор фильтра самого грида, пользователь обычно туда не лезет. Еще думаю добавить кнопку для быстрого добавления условия фильтрации "текущее поле=текущему значению". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.10.2013, 17:05 |
|
||
|
Набросал структуру для генерации GUI
|
|||
|---|---|---|---|
|
#18+
Еще забавно, что клиенту в общем-то совсем без разницы, на сервере ли БД лежит логика или на сервере приложений. Ему достаточно получать данные для отображения и вызывать процедуры с параметрами. Т.е. в перспективе можно переложить логику в среднее звено, сделать клиента в браузере, или научить этого же клиента работать через tcp/ip (т.е. не только в интрасети) не с БД а с промежуточным сервером, который может выполнять процедуры хоть в БД хоть в AppServer. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2013, 13:24 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1541091]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
152ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 500ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...