|
Как спроектировать механизм вызова и привязки форм?
|
|||
---|---|---|---|
#18+
Очень нужен профессиональный совет. Ситуация: строится небольшая учетная система (склад + торговля). (DotNet + MS SQL2000). Уже имеются формы журналов справочников. Некоторые из форм проектируются вручную, другие (если не нужна особая специфика) генерируются на лету через наследование от базового класса "Журнал справочника" - в конструктор такого класса-шаблона передается информация о типе, например "физ лица". Проблема состоит в том, что созданный таким образом экземпляр класса "Журнал" должен уметь вызывать и привязывать к нужной строке форму элемента нужного типа. Например, если открыта форма "Журнал физ лиц", то выбрав конкретную строку надо уметь из нее открыть для редактирования форму редактирования элемента "Физ лицо". Пока не совсем понимаю как в точности это сделать. Должен ли за генерацию и вызов дочерней формы отвечать конкретный элемент родительской формы (в данном случае - "Табличное поле" - DataGrid) или же это ответственность конкретной строки или наоборот - всей формы? Вероятно все-таки табличное поле. Как именно надо расширить базовый класс такого элемента "Табличное поле", чтобы он мог вызывать необходимую ему форму, привязывать ее к себе и затем уметь отслеживать и обрабатывать результат, когда дочерняя форма закрылась - как организовать возврат информации о результате: прередать в дочернюю форму адрес некоторой функции для обратного вызова (как получить такую функцию в рамках шаблона?) или передать ссылку на родительскую форму и каким-то образом пытаться перехвать событие закрытия дочерней? Аналогично: как научить различные элементы формы (например текстовое поле) вызывать форму выбора или форму редактирования нужного типа и обрабатывать результат? Заранее спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2006, 12:17 |
|
Как спроектировать механизм вызова и привязки форм?
|
|||
---|---|---|---|
#18+
Делаю таблицу привязок между формами(справочниками). Например: Из Ф1 можно вызвать Ф2 и Ф5. Для правильности формирования из дочерней формы в родительскую передаю Datasource->MasterSource (Delphi), ключевое поле (для дальнейшего Locate к нему), и контекст безопасности(права, признаки ReadOnly) в разрезе юзера ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2006, 13:29 |
|
Как спроектировать механизм вызова и привязки форм?
|
|||
---|---|---|---|
#18+
LSVДелаю таблицу привязок между формами(справочниками). Например: Из Ф1 можно вызвать Ф2 и Ф5. Для правильности формирования из дочерней формы в родительскую передаю Datasource->MasterSource (Delphi), ключевое поле (для дальнейшего Locate к нему), и контекст безопасности(права, признаки ReadOnly) в разрезе юзера то есть, открываем форму журнала Ф1 - она должна иметь реквизит МойТип = Ф1 и, затем, когда надо открыть форму редактирования элемента по текущей строке - обращаемся к глобальной функции вида Ф = СоздатьФормуЭлемента(ТипРодителя=Ф1, параметр=код_из_текущей_строки) - а в этой функции выясняем, что для Ф1 формой элемента может быть только скажем Ф5. Если правильно понял... Но это только для формы журнала. А для формы с несколькими текстовыми полями - Вы как-то в них храните информацию о том, какому типу относятся отображаемые текстовые данные? Иначе придется все обработчики событий "Выбрать элемент" писать к ним вручную. Кроме того, если в форме журнала разрешено редактирование прямо в строке, то для разных клеток должны вызываться разные типы форм и надо тогда хранить информацию о типе для каждой колонки табличного поля... ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2006, 16:06 |
|
Как спроектировать механизм вызова и привязки форм?
|
|||
---|---|---|---|
#18+
jsq С моей точки зрения, в подобной ситуации наиболее эффективным является внести руками некоторое количество конфигурационной информации. Безусловно, в формах редактирования справочников можно сделать абсолютно универсальный код, работающий практически сам по себе - но некоторые вещи автоматизировать просто неэффективно. Допустим, такая задача - справочник имеет ссылки на другие справочники. При редактировании записи, соответственно, кнопка около соответствующего поля должна вызывать окно выбора из второго справочника. Да, можно написать код, который проанализирует и учтет все внешние ключи, учтет конвенцию именования, согласно которой, допустим, встречая поле xxxx_id нужно рисовать значение из поля xxxx_name, осуществит поиск среди справочников формы, отвечающей за работу с xxxx итп. После этого выяснится, что где-то позарез нужен выбор из справочника при отсутствии внешнего ключа; где-то должна вызываться не стандартная форма справочника, а специфическая итп. В итоге поддержка такого решения выльется опять же в достаточно заметные трудозатраты. Следовательно, важнейшим действием является поиск оптимума. Внести в программу информацию типа "для справочника такого-то поле такое-то связано так-то с таким-то справочником, форма выбора такая-то" становится наиболее удачным решением. Разумеется, провести границу - что полностью автоматизировать, что конфигурировать, что дописывать руками - достаточно сложное и безусловно ответственное решение. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2006, 16:12 |
|
|
start [/forum/topic.php?fid=33&msg=33513002&tid=1549465]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
292ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 407ms |
0 / 0 |