Визуальное наследование, Суслики(с) и оффтопики в чужих ветках

← →
Sergey_Masloff (2004-11-03 11:04) [0]

Ну в смысле чтобы не оффтопить. Суслик(с) ты туда не пиши ты сюда пиши (если есть желание). Про формы в бизнес-логике.
Тема знакомая но нестареющая. Так что там про генеренье форм из бизнес-логики? Можешь на пальцах привести пример?
Ну я к тому что или формы ОЧЕНЬ простые или их описание в БИЗНЕС-логике на фиг не нужно. Или ты просто имеешь в виду что хранишь их описание в СУБД например?

← →
}|{yk © (2004-11-03 11:07) [1]

Гм... А мой вариант к чему относится?
http://www.delphimaster.ru/articles/frames/index.html

← →
Игорь Шевченко © (2004-11-03 11:10) [2]

Дабы не засорять ту ветку.

Юрий Федоров © (03.11.04 10:40) [59]

> Если имеется в виду наследование визуальное - я в последнее
> время прихожу к мнению, что для больших проектов этот отказ
> обоснован. Разумеется не полный отказ, отказ в большом количестве
> случаев.

Слава Аллаху, что Borland думает иначе. Впрочем, если хочется наращивать мускулатуру пальцев, то флаг в руки.

← →
Юрий Федоров © (2004-11-03 11:13) [3]

> [2] Игорь Шевченко

Я не сторонник запрета Борландом визуального наследования
:-)))))

по сабжу
есть, например, форма предок и пара десятков потомков ,в каждом по 10-100 строк кода.
Предлагаешь для каждой держать свой модуль?

← →
Sergey_Masloff (2004-11-03 11:21) [4]

Юрий Федоров © (03.11.04 11:13) [3]
>есть, например, форма предок и пара десятков потомков ,в каждом >по 10-100 строк кода.
>Предлагаешь для каждой держать свой модуль?
Почему нет? Если эти 10 строк используются только в ней а визуально она отличается сильно? Вобщем, проблемы большой не видно.
Еще доводы? ;-)

← →
Юрий Федоров © (2004-11-03 11:30) [5]

> [4] Sergey_Masloff

А если 50 форм? И если они визуально отличаются совсем не сильно?
:-)
Это ли не сильнейшее увелничение общей бардачности проекта ?

Второй довод - от Суслика
формирование на лету, исходя из метаданных

Результирующая накачанность пальцев в результате пониижается, а вовсе не повышается

← →
by © (2004-11-03 11:47) [6]

Я столкнулся с такими проблемами когда понадобилось создать много практически одинаковых справочников. Они все делались методом Copy/Paste и на пятом уже пришло сомнение, программист я или ксерокс?. Вот тогда и задумался что по крайней мере справочники проекта должны генерится из метаданных.

← →
wisekaa © (2004-11-03 11:49) [7]

Можно поинтересоваться о каких формах идет речь?
Потому, что формирование форм первичного ввода документов на лету я представляю как-то слабо, вот использование фраймов для одинаково повторяющихся элементов ввода это да, но как формировать на лету?

Если речь идет о формах результирующих (ввыда графиков, таблиц ..) тогда это я могу понять. Но в этом случае действительно не обязательно генерить 2,3 ... форму, всю уникальность работы можно реализовать в одной форме.

← →
Игорь Шевченко © (2004-11-03 11:53) [8]

Юрий Федоров © (03.11.04 11:13) [3]

> по сабжу
> есть, например, форма предок и пара десятков потомков ,в
> каждом по 10-100 строк кода.
> Предлагаешь для каждой держать свой модуль?

Почему нет ? По крайней мере, я так и делаю, проблем, вроде, не испытываю.

← →
Sergey_Masloff (2004-11-03 11:53) [9]

Юрий Федоров © (03.11.04 11:30) [5]
>А если 50 форм? И если они визуально отличаются совсем не >сильно?
Да хоть 500 ;-) Если не отличаются визуально (или практически не отличаются) то это 1 форма. Если отличие визуальное есть то пусть хоть 5000 - ничего страшного не будет.

>Второй довод - от Суслика
>формирование на лету, исходя из метаданных
На это я уже сказал - или формы очень простые или все это баловство и накачка пальцев ;-) Потому что сложную форму и просто рисовать замучаешься чтобы эргономичной была, а уж описывать в метаданных... Свой аналог DFM с элайнами, анкорами и так далее - ИМХО муторно да и к бизнес - логике мало отношения имеет, собственно говоря.
Про уменьшение качки пальцев - так эдитов на форме ровным слоем рассыпать автоматически не проблема. Или типа обджект инспектора - свойство значение тоже без проблем. Только удобно ли это юзеру? Не факт.

Но это конечно дело привычки. Не претендую на абсолют
Кстати у меня например есть форма универсального отбора по базе. И ее наследники - действительно штук 50. Которые отличаются от базовой 1 (одной) строчкой кода. И та несет функцию вспомогательную.
Когда нужен новый отбор кто-то (обычно не я так как работа чисто механическая) наследует форму, кидает на нее необходимые контролы, дает им (контролам) имена и все. Его работа закончена. Никакого кода он не пишет - это просто не нужно.
Бардак при этом АБСОЛЮТНО не увеличивается. Весь код при этом в 1 форме а остальные - просто маски для нее - одна позволяет задать 5 критериев отбора вторая - 150 и все отличие.

← →
KSergey © (2004-11-03 11:56) [10]

Люди, об чем базар - можно узнать? (ссылку бы тут на изначальное обсуждение...)

← →
Sergey_Masloff (2004-11-03 11:57) [11]

Да, добавлю естественно все эти 50 форм для отбора РАЗНЫХ сущностей а не для разных комбинаций отбора одного и того же. А то подумаете еще фиг знает что ;-)

← →
Юрий Федоров © (2004-11-03 12:07) [12]

> [8] Игорь Шевченко

50 модулей надо ведь как то еще назвать, так, чтобы было понятно ,что в нем ,а потом еще и быстро найти нужный при необходимости.
50 идентификаторов - имен классов в данном случае неизбежно, а дополнительных 50 с именами модулей можно избежать

> [9] Sergey_Masloff

Говорю ту же фразу, но первое слово 5000 :-)))

> Свой аналог DFM...

Зачем анаалог? Можно использовать сам формат DFM и хранить его, например ,в Блоб поле

Впрочем, на абсолют тоже не претендую - это зависит от задачи

> [10] KSergey ©

Началось с моей ветки про вакансию

← →
KSergey © (2004-11-03 12:12) [13]

> [12] Юрий Федоров © (03.11.04 12:07)
> Началось с моей ветки про вакансию

Эк вас всех занесло! =8-))

← →
Игорь Шевченко © (2004-11-03 12:13) [14]

Юрий Федоров © (03.11.04 12:07) [12]

> 50 модулей надо ведь как то еще назвать, так, чтобы было
> понятно ,что в нем ,а потом еще и быстро найти нужный при
> необходимости.
> 50 идентификаторов - имен классов в данном случае неизбежно,
> а дополнительных 50 с именами модулей можно избежать

А назвать модули по именам классов не судьба ? Юра, по-моему, проблема на пустом месте. На предмет быстро найти - так классы тоже надо искать.

← →
Суслик © (2004-11-03 12:15) [15]

Давай определю, что я считаю метаданными.

Метаданные в моем понимании это данные о данных. Данные о данных, сами понимаете, накладывают существенные ограничения на структру самих данных.

Хорошим аналогом может служить схема xml - это данные о данных.

Как я уже сказал, метаданные ограничивают сами данные. Т.е. допускают только определенные данные.

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

Пример.
Есть у меня бизнес объект. Это объект среднего слоя. В настоящий момент он сидит в толстом клиенте, но его можно в полной мере назвать средним слоем (согласно терминологии Фаулера из книги Архитектура корпоративных прораммных приложений). Этот объект и его потомки обеспечивают полноту бизнес-транзакций, основываясь над системными тарнзакциями mssql server. Проблемы бизнес-блокировок (не системных !!!) ложаться на этот слой. Также здесь находится контроль за согласованным чтением, уровнями изоляции и пр.

Этот объект построен на следующих принципах:
1) Каждый объект относится либо к независимым либо к зависимым объектам.
2) Независимые владеют как зависимыми, так и независимыми объектами.
3) Бизнес-транзакции, если не сказано иного, ограничиваются независимыми объектами (но транзакция может быть шире).
4) Каждый объект состоит из простытх полей и контейнеров других объектов.
5) Незавимые объекты отвечают за livetime подчиненных (т.е. как owner в delphi).
6) Есть metadata mapper, который проецирует объекты на базу данных и обратно согласно метаинформации о самих объектах.

Не хотел бы вдаваться сильно в методику хранения метаинфорации класса скажу, что она сделана так, что существует в единственном экземпляре для класса, но не для объекта и к тому же наследуется (реализовано на class function).

Но! Хотел бы сказать, что той метаинформации, которая есть, достаточно для того, чтобы:
1) проецировать класс в базу и обратно (это я сказал выше)
2) проецировать класс на экран и обратно.

П. 2 я делаю примерно так:
1. Создаю экземпляр формы TObjectEditor
2. Передаю ей класс.
3. Форма анализируя состав метаинформации класса и его пожелания к отображению строит компоненты и привязывает их к данным.

Да, не спорю, что такая методика не позволяет делать все страшно красиво. Но, как я думаю, для учетных систем это не важно.

← →
Юрий Федоров © (2004-11-03 12:15) [16]

> [6] by

> сомнение, программист я или ксерокс?.

в данном случае формирование из метаданных как раз может быть не обязательно, достаточно наследования.
а вот какое оно - должно быть, визуальное или нет, зависит от объема своего кода для каждой формы, имхо

← →
Sergey_Masloff (2004-11-03 12:17) [17]

Вобщем, пока я вижу только 1 плюс - меняешь метаданные на сервере и счастливые клиенты тут же без перекомпиляции начинают работать по-новому. У себя я это использую но в несколько другом виде - на сервере хранятся видимости-невидимости и доступность контролов, маски ввода и подобная ерунда. Сами формы держать смысла особого для себя не вижу так как если глобально меняется форма то наверное и код придется пописать и городить на клиенте еще и интерпретатор - это уж совсем слишком ;-)

← →
Юрий Федоров © (2004-11-03 12:22) [18]

> [14] Игорь Шевченко

Хорошо. По большому счету это дело вкуса, как сделать. Лично мне большое количество файлов в папке проекта не нравится

Что лично мне еще не нравится в визуальном наследовании.
Одно неверное движение мышкой (дрогнула рука) - и мы в ....
причем сразу можем не заметить
например, слетит обработчик OnCkick кнопки

← →
Суслик © (2004-11-03 12:25) [19]

> [18] Юрий Федоров © (03.11.04 12:22)

ну щас тебя обвинят - не умеешь не берись, а хаять дельфи не смей :)

← →
Sergey_Masloff (2004-11-03 12:25) [20]

Суслик © (03.11.04 12:15) [15]
>Давай определю, что я считаю метаданными.
Тут все правильно

>Поэтому, хорошо зная бизнес-логику своей системы, я иду на >определенные ограничения, которые хорошо поддаются формальному >описанию.
Тут пока непонятно

>Пример.
>Есть у меня бизнес объект. Это объект среднего слоя. В >настоящий момент он сидит в толстом клиенте, но его можно в >полной мере назвать средним слоем (согласно терминологии
Это опять понятно

>6) Есть metadata mapper, который проецирует объекты на базу >данных и обратно согласно метаинформации о самих объектах.
Это, в принципе, тоже понятно

>Не хотел бы вдаваться сильно в методику хранения метаинфорации >класса скажу, что она сделана так, что существует в >единственном экземпляре для класса, но не для объекта и к тому >же наследуется (реализовано на class function).
Это интересно бы посмотреть

>П. 2 я делаю примерно так:
>1. Создаю экземпляр формы TObjectEditor
>2. Передаю ей класс.
>3. Форма анализируя состав метаинформации класса и его >пожелания к отображению строит компоненты и привязывает их к >данным.
Да, это примерно понятно. Просто хотелось бы мне посмотреть на пример формы. Можешь мне на емейл прислать любой скриншот? Конфиденциальность гарантирую, 1 раз посмотрю и изничтожу. Может, конечно, нашловатая просьба можешь игнорировать - я пойму ;-)

← →
Sergey_Masloff (2004-11-03 12:26) [21]

> нашловатая
нагловатая в смысле

← →
Игорь Шевченко © (2004-11-03 12:32) [22]

Юрий Федоров © (03.11.04 12:22) [18]

> Хорошо. По большому счету это дело вкуса, как сделать. Лично
> мне большое количество файлов в папке проекта не нравится

Лично мне не нравится писать лишний код. Пусть даже из таких эстетических соображений, как количество файлов в папке проекта.
Hint: папку проекта можно разбить по подпапкам.

> Что лично мне еще не нравится в визуальном наследовании.
> Одно неверное движение мышкой (дрогнула рука) - и мы в ....
>
> причем сразу можем не заметить
> например, слетит обработчик OnCkick кнопки

Ни разу не сталкивался с тем, чтобы регулярно что-то слетало. Кроме того, исправляется это легко, а тестирования еще никто не отменял.
С другой стороны, чем больше строк кода в модуле, тем труднее туда вносить изменения.

← →
Суслик © (2004-11-03 12:32) [23]

> [20] Sergey_Masloff (03.11.04 12:25)

Не, ну чето присылать - форма, как форма, хотя держи

> Это интересно бы посмотреть

Я бы не против, но только тема долгая. Я как-то хотел статью написать. Но ИШ сказал, что эта тема мышами прогрызена и все нормальные программеры это и так знают.

← →
Игорь Шевченко © (2004-11-03 12:42) [24]

Суслик © (03.11.04 12:32) [23]

> Я как-то хотел статью написать. Но ИШ сказал, что эта тема
> мышами прогрызена и все нормальные программеры это и так
> знают.

Ну-ну. Факты не будем искажать, да ?

← →
Суслик © (2004-11-03 12:46) [25]

> [24] Игорь Шевченко © (03.11.04 12:42)

> Ну-ну. Факты не будем искажать, да ?

Про серьезных программеров я придумал. Ну ты не в обиде? :)
А про мышей все честно сказал - именно такие слова и были.
(hint: как выяснилось, к приспособленцу это отношение не имеет).

← →
Игорь Шевченко © (2004-11-03 12:48) [26]

Суслик © (03.11.04 12:46) [25]

У меня просьба - ламерство в себе изживай, пожалуйста.

← →
Суслик © (2004-11-03 12:51) [27]

> [26] Игорь Шевченко © (03.11.04 12:48)

> У меня просьба - ламерство в себе изживай, пожалуйста.

Ну уж нафиг - где тогда тебе и некоторым иным членам нашего сообщества душу отводить. Тебе станет скучно и пропадет интерес к форуму. Мне бы этого не хотелось.

Вынужденные 2-3 недели отсутствия на форму мне очень помогли переосмыслить термин "ламер". Можно только без пояснений? А?

← →
Sergey_Masloff (2004-11-03 12:54) [28]

Суслик © (03.11.04 12:32) [23]
Посмотрел в принципе действительно форма как форма - просто виденное до этого сделаное в такой идеологии смотрелось довольно убого. В твоем варианте - нормально. Но я думаю довольно много приходится классу обрабатывать чтобы нарисовать подобное.
То есть фактически у тебя форма - универсальный "клиент" на котором твои объекты могут себя рисовать? Или форма умеет рисовать объект?
К сожалению до вечера выпадаю из дискуссии. Но вечером подключусь если еще кому-то будет интересна эта ветка.

Хранение визуальных в метаданных имеет два существенных недостатка:
1. Если один клиент изменил, к примеру, отчет, то у всех остальных этот отчет тоже будет новый. То же самое касается форм, гридов и т.д. Хранить же в метаданных версии для каждого клиента или держать еще и "апдейты" в локальных папках - это уже монстроидально.
2. При коррекции (программной) кода чрезвычайно затруднительно как разобраться в самой модифицируемой картинке (ее же непосредственно не видно), так и в логике взаимосвязей различных частей интерфейса, привязки к сущностям БД, бизнес-логики и т.д. Это частенько ведет к появлению неявных ошибок, которые имеют свойства вылазить "как только вышел за двери"

>
> Sergey_Masloff (03.11.04 12:54) [28]
> Суслик © (03.11.04 12:32) [23]
> Посмотрел в принципе действительно форма как форма - просто
> виденное до этого сделаное в такой идеологии смотрелось
> довольно убого. В твоем варианте - нормально.

Дайте картинку в студию, тоже посмотреть охота.

> [28] Sergey_Masloff (03.11.04 12:54)

> я думаю довольно много приходится классу обрабатывать чтобы
> нарисовать подобное.

Кое где применен подход java (когда-то давно читал про это) - говоришь, что хочешь, а форма сама делает. Например, говоришь, что хочешь расположить такие то одиночные поля - форма сама их располагает, чтобы было красиво.

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

В общем писать приходится немало, но я не вижу (по своему опыту ничего в этом плохого). Поддержание кода, как мне кажется, легче, чем разрозненной информации из ресурсов.

> Дайте картинку в студию, тоже посмотреть охота.

Не дам - лень.

Поверь, форма как форма, без 3d анимации и встроенного тетриса, конечно. Но ничем не хуже тех, которые пишешь ручками с dbgrid и сотоварищи.

Суслик © (03.11.04 13:00) [32]
А наследование как реализовано?
Например Если на форме A нужно добавить кнопочку.
1. Создается форма А и присобачивается кнопка
2. Ctrl+C всей формы А Ctrl+V в ворму B и еще создание кнопки.

КаПиБаРа © (03.11.04 13:22) [33]
Например Если на форме A нужно добавить кнопочку.

Например, если нужна форма B такая же как форма A? только с еще одной кнопочкой.

> [33] КаПиБаРа © (03.11.04 13:22)

> А наследование как реализовано?

У форм нет наследования. Есть одна универсальная форма, получающая в зубы объект, с которым нужно работать. Вот объекты уже могут наследоваться. Форме по фигу.

ЗЫ. Добавлять кнопочки мне пока не приходилось. Когда-то давно, когда это все только рождалось в лучае потребности в чем-то новом я лез в метаданные и что-то там добавлял. Сейчас уже охвачено большинство нужных именно этой программе визуальных элементов. Т.е. больше не лезу.

Суслик © (03.11.04 13:27) [35]
Хорошо заменим слово форма на объект а кнопочку на что нить еще.
Так все таки вариант 1 или 2.

> [36] КаПиБаРа © (03.11.04 13:30)

> Так все таки вариант 1 или 2.

Очень сильно зависит от лежащей в основе объектов логики.
Т.к. база объектная (вернее есть объектный mapper между реляционкой и объектной моделью), то подмывает делать все наследованием. Опыт применения такого подхода показывает, что есть случае, когда ведение параллельных линий похожих но не идентичных объектов лучше. В частности это выражается в том, что рефакторинг данных сложнее рефакторинга кода. И переработать БД с целью возниктновения в таком деле сложно. Поэтому у нас чаще другой подход - потребность в общем предке осознается только на основе опыта применения, а не наоборот. Когда предок таки выделен в дальнейшем он используется при наследовании. Успех подобного выделения зависит от продуманности такого решения. Были случаи, когда это мешало. Особенно когда объединение происходит на основе формальных признаков без учета семантики (возможно в будущем) конкретных объектов.

> [37] Суслик © (03.11.04 13:37)

Хотел бы добавить, что, безусловно, общий предок, содержащий в себе очень много есть. Описанный мной подход кассается небольших частных добавок. В общем случае, конечно, основной код в предке.

>msguns © (03.11.04 12:56) [29]
>Хранение визуальных в метаданных имеет два существенных >недостатка:

Если добавить к этому способу еще обработку кнопок и некоторых событий, то мы так и делаем. Идеальный вариант при поддержке. А если нужно чтобы варианты были разные есть способ - если на локал. машине или ее папке в сет есть вариант этой формы, он берется оттуда, если нет, из общей папки. Действительно универсальный вариант.

Визуальное наследование, Суслики(с) и оффтопики в чужих ветках Найти похожие ветки