-
Ситуация следующая: надо унаследоваться от базового фрейма с парой контролов и несколькими методами-свойствами.
Как это сделать в принципе - понятно: наваял в design-time базовый фрейм, засунул в репозиторий, а дальше - New Item и включить inherit
вопрос в следующем: а что будет при командной разработке? Т.е. каким макаром импортировать базовый фрейм с dfm с одной машины на другую (или в систему контроля версий)?
Можно ли как-то унаследоваться от фрейма без возни с ресурс-файлами?
-
Разобрался, вопрос снят.
-
Вот честно не встречал подводных камней с наследованием фреймов.
Хотя, грешен, использую :)
> Разобрался, вопрос снят.
Из правил форума, пункт 9
"В случае, если поставленная проблема решена, написать в ветке решение — возможно Ваша информация поможет другим участникам. "
-
-
Германн © (19.03.08 00:59) [3]
Я вот не всегда понимаю, зачем хранить формы в базе :)
А как же код к ним ?
-
> Игорь Шевченко © (19.03.08 01:54) [4]
>
> Германн © (19.03.08 00:59) [3]
>
> Я вот не всегда понимаю, зачем хранить формы в базе :)
>
> А как же код к ним ?
>
Ну, это всё-таки не ко мне.
-
> Я вот не всегда понимаю, зачем хранить формы в базе :)
Я не храню форму в базе. В базе хранится значение некоего типа данных. Этому типу соответствует собственный PropertyFrame.
-
> Игорь Шевченко © (19.03.08 01:54) [4]
При желании вполне срастается. Зачем - это уже другой вопрос. Например, для того, чтобы каждый юзер мог иметь свой собственный экранный интерфейс (а в более продвинутом варианте - сам же его и создавать).
-
Семеныч (19.03.08 09:39) [7]
> При желании вполне срастается.
В древнем Китае желающим странного отрубали голову. Мудрые были люди, не находишь ?
> Например, для того, чтобы каждый юзер мог иметь свой собственный
> экранный интерфейс (а в более продвинутом варианте - сам
> же его и создавать).
А код тоже писать и в базе хранить ?
-
> Игорь Шевченко © (19.03.08 09:57) [8]
> В древнем Китае желающим странного отрубали голову. Мудрые были
> люди, не находишь?
Нахожу, но при условии, что древние китайцы располагали абсолютно безошибочным определителем, того что есть странное, а что - нет.
В чем есть большие сомнения. Понятие "странное" весьма сильно зависит от задачи - а задачи очень разными бывают.
> А код тоже писать и в базе хранить ?
Еще раз: при желании закомпилированный в EXE код прекрасно срастается с DFM, которая хранится в БД. Иначе и быть не может: если код срастается с DFM, хранящимися в ресурсах программы, то почему бы ему не срастаться с DFM, хранящимися в БД? Не все ли равно, откуда грузить DFM? Коду это, в общем-то, до лампочки - его только надо грамотно написать.
ПыСы
Кстати, ежели заглянуть в ToolsAPI, то там увидим, что file system можно переопределить - и тогда даже саму IDE можно научить работать с формами не из файлов, из БД (да и вообще откуда угодно). Прямо в design-time. Разработчики это предусмотрели - и мне не кажется, что они возжелали странного. Потому что задачи разными бывают.
-
Семеныч (19.03.08 10:18) [9]
> при желании закомпилированный в EXE код прекрасно срастается
> с DFM, которая хранится в БД. Иначе и быть не может: если
> код срастается с DFM, хранящимися в ресурсах программы,
> то почему бы ему не срастаться с DFM, хранящимися в БД?
> Не все ли равно, откуда грузить DFM? Коду это, в общем-то,
> до лампочки - его только надо грамотно написать.
Не...есть еще один момент, что для каждого класса, кроме формы генерируется VMT - и он содержит в себе все published поля, методы и т.д. Грубо говоря, ты не можешь произвольному классу назначить произвольный ресурс,
они должны быть синхронизированы. При компиляции эта синхронизация обеспечивается,
а как ее обеспечить при загрузке из базы - извини, не знаю :)
-
> Игорь Шевченко © (19.03.08 12:50) [10]
> а как ее обеспечить при загрузке из базы - извини, не знаю :)
Очень просто - несколько хранящихся в БД форм имеют один и тот же класс, но могут иметь разное визуальное представление.
-
Семеныч (19.03.08 13:02) [11]
> Очень просто - несколько хранящихся в БД форм имеют один
> и тот же класс, но могут иметь разное визуальное представление.
>
Ну это и есть желание странного - одному с рюшечками, другому чтобы edit был справа, третьему чтобы слева и красного цвета :)
-
> Ну это и есть желание странного - одному с рюшечками, другому
> чтобы edit был справа
Скины. Есть любители этого дела )
Хотя, лично я тоже не разделяю... Если надо работать, то главное -- чтоб ехало, а не шашечки )
-
> Игорь Шевченко © (19.03.08 13:17) [12]
Все намного хитрее. Загруженная форма имеет свой ID и в зависимости от него может меняться логика работы кода. Так что тут далеко не рюшечки.
-
Семеныч (19.03.08 13:21) [14]
Ясно. Переложение обнаружения ошибок с этапа компиляции на этап выполнения.
"Бывает нечто, о чем говорят: "смотри, вот это новое"; но это было уже в веках, бывших прежде нас."
Еккл. 1.10
-
> Игорь Шевченко © (19.03.08 13:25) [15]
???
Как понять тебя, Саид? При чем тут переложение обнаружения ошибок?
Ты уверен, что хорошо понял суть подхода?
ПыСы.
Бедняги классики. Если бы они знали, КАК будут пользоваться их высказываниями, они, пожалуй, от оных воздержались бы.
-
Семеныч (19.03.08 13:32) [16]
> При чем тут переложение обнаружения ошибок?
Я насмотрелся на различные динамические подходы - давайте мы будем загружать, а код у нас будет универсальный для всех случаев. В большинстве своем это приводит именно к тому, что при компиляции все хорошо - как же, код универсальный, а во время выполнения вылезают ошибки.
Наиболее иллюстирующий пример - это обильное использование типа Variant.
Ну не понимаю я, зачем формы в базе хранить. Формы в EXEшнике или в DLL-ях должны жить, самое им там место. Опять же, дабы синхронизацию выполнял компилятор, а не хитрый код во время выполнения.
-
> Игорь Шевченко © (19.03.08 14:03) [17]
> а во время выполнения вылезают ошибки.
Если руки у программеров заточены криво, то чем виновата архитектура приложения?
> Ну не понимаю я, зачем формы в базе хранить.
Если некто чего-то не понимает, то разве это означает, что это что-то плохое или ненужное?
-
Семеныч (19.03.08 15:03) [18]
> Если руки у программеров заточены криво, то чем виновата
> архитектура приложения?
Кроме дополнительного геморроя разработчикам - ничем. А можно пример оправданной необходимости такой архитектуры приложения ?
> Если некто чего-то не понимает, то разве это означает, что
> это что-то плохое или ненужное?
Это означает, что это странное. См. пост о древнем Китае.
-
> Игорь Шевченко © (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 (притом, довольно навороченный) создается кодом. И для той задачи это, видимо, оправдано.
-
-
> со своим внутренним языком, как это делает та же 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 компоненты.
|
Есть новые 
Нет новых [134484 +49][b:0][p:0.001]