> Игорь Шевченко ©   (19.03.08 15:11) [19]

>> Если некто чего-то не понимает, то разве это означает, что
>> это что-то плохое или ненужное?

> Это означает, что это странное. См. пост о древнем Китае.

Нет, Игорь. Это означат только то, что некто чего-то не понимает. И больше ничего не означает. Даже если этому некоему оно и кажется странным (что и естественно, раз он не понимает).

А что касается поста древнего Китая, то см. пост об абсолютно безошибочном определителе. Ты же таковым себя не считаешь, верно?
:о)

Семеныч   (19.03.08 15:45) [20]

А можно пример оправданной необходимости такой архитектуры приложения ?

> Игорь Шевченко ©   (19.03.08 15:49) [21]

Можно, конечно.

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

Таких клиентов несколько десятков, и их количество продолжает расти. Что делать? Дорабатывать и перекомпилячивать проект под каждого? Или что еще?

> [22] Семеныч   (19.03.08 18:41)
> > Игорь Шевченко ©   (19.03.08 15:49) [21]
>
> Можно, конечно.
>
> Продукт класса ERP. Понятное дело, требуется адаптация под
> каждого клиента. Кто-то просит ввести еще один тип накладной,
> кому-то нравятся рюшечки слева (и он готов за них платить)
> , а главное то, что у каждого из них еще и свои особенности
> бизнес-логики.
>
> Таких клиентов несколько десятков, и их количество продолжает
> расти. Что делать? Дорабатывать и перекомпилячивать проект
> под каждого? Или что еще?

Ну дык «дорабатывать» все-равно придется. Только в в предложенном вами варианте придется дорабатывать сущности, которые компилятор не проконтроллирует, т.е., риск невыявленных ошибок повышается. А «перекомпилячить», наверное, это не так уж и сложно, учитывая то, что Делфи компилирует очень быстро :)
А для отделения ветвей текущего продукта давно придумали системы контроля версий :)

> Джо ©   (19.03.08 19:15) [23]

> «дорабатывать» все-равно придется.

Не обязательно.

> «перекомпилячить», наверное, это не так уж и сложно

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

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

==========================

Наводящий вопрос - а как решена проблема адаптации и поддержки, например, в 1С? Там ведь даже не десятки, там тысячи клиентов.

Семеныч   (19.03.08 18:41) [22]


> Продукт класса ERP. Понятное дело, требуется адаптация под
> каждого клиента



> Кто-то просит ввести еще один тип накладной, кому-то нравятся
> рюшечки слева (и он готов за них платить)


Продукты класса ERP хорошо писать на своем движке, со своим внутренним языком, как это делает та же 1С.


> а главное то, что у каждого из них еще и свои особенности
> бизнес-логики.


Тем более, с учетом разной бызнес логики.

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

> Игорь Шевченко ©   (19.03.08 20:05) [25]

> Продукты класса ERP хорошо писать на своем движке, со своим
> внутренним языком, как это делает та же 1С.

Угу. Начинаем подбираться к сути вопроса "зачем нужны формы в БД". А если б еще и на на наводящий вопрос кто ответил, то оно и быстрее было бы.

> С какого боку тут формы в базе

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

===================================

Игорь, при всех этих десятках клиентов, адаптации под них, прикруткой рюшечек и разной бизнес-логики проект не перекомпилируется вообще. В нем при этом ни один байт не меняется. А группа внедрения и поддержки не разрастается и не требует ни одной лицензии Delphi.

И формы в БД - это одна из составляющих, которые в совокупности это обеспечивают.

Семеныч   (19.03.08 20:16) [26]

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

> Игорь Шевченко ©   (19.03.08 21:01) [27]

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

Кроме того, есть визуальный редактор форм (с палитрой компонентов, Инспектором объектов и пр.). Таким образом, без какой-либо перекомпиляции программы можно изменить ее функционал и GUI (вплоть до замены главной формы) чуть ли не полностью. Причем не только под какую-то контору, а хоть персонально под каждого юзера (или роль).

И это под силу IT-шнику, НЕпрограммисту. И не требует Delphi с ее лицензией. И формы в БД - это одна из составляющих, которые в совокупности все это обеспечивают.
:о)

Семеныч   (19.03.08 21:20) [28]

Так бы сразу и сказал :) В этом случае безусловно имеет смысл хранить.

> Игорь Шевченко ©   (19.03.08 22:45) [29]

> Так бы сразу и сказал

Так я сразу я сказал, что задачи бывают разными. Например, знаю программу, где DFM, можно сказать, и вовсе нет - GUI (притом, довольно навороченный) создается кодом. И для той задачи это, видимо, оправдано.

> Ну это и есть желание странного - одному с рюшечками, другому
> чтобы edit был справа

http://habrahabr.ru/pictures/00/00/01/60/37/picture_12.jpg

> со своим внутренним языком, как это делает та же 1С.

Ну, положим, 1С решила этот вопрос просто - пользует визуал басик и не парится. Только классы для своих примочек написали.

Впрочем, каюсь, я тоже полноценный компилятор поленился писать - за меня оракл работает :)

> А можно пример оправданной необходимости такой архитектуры
> приложения ?
>


Пример из реальной жизни.
Задача: обновление абстрактной БД (патч на структуру + добавление некоторых записей в справочники + обновление ХП).
Ограничения: нужно сделать так, чтобы эта "обновлялка" максимально приблизилась к интрепритируему языку (простите за формулировку, но у товарища день рождения и я сейчас пьян).

Вариант решения:
Практически у любой СУБД есть утилита командной строки, с помощью которой можно СУБД "скормить" некий скрипт (или набор скриптов).
Готовим cmd-файл, в который в качестве параметров передаём параметры коннекта.
Соответственно, готовим некий конфигурационный файл в любом доступном для программы формате (сделаны варианты на ini, xml, в данный момент осваивается YAML).
Данный конфигурационный файл регистрируется со своим расширением, к этому расширению привязывается программа.
Файл состоит из следующих "секций":
1. FormCaption
2. Набор параметров. Каждвй параметр:
 2.1. Имя.
 2.2. Тип параметра.
 2.3. Caption параметра
 2.4. Default Value
3. Параметризованая командная строка

Программа на входе получает этот файл, выставляет Caption, далее генерит нужное количество фреймов в зависимости от типа.
На кнопке "ОК" висит обработчик, заменяющий параметризованую командную строку введёнными параметрами и далее выполняющий RunAndWait (за функцию в который раз спасибо Игорь Шевченко ©).
После чего выводит результат выполнения и умирает.

> Семеныч   (19.03.08 21:20) [28]


Вот аккурат такую штуку реализовали на прошлой работе. Работет в Дагестане.  :)

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

Начет наследования фреймов - бывает оно глючит. Теряет где то свойства предков особенно DB компоненты.