| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Наследование фреймов - подводные камни [D7]
Ega23 © (2008-03-18 18:10:00)Ситуация следующая: надо унаследоваться от базового фрейма с парой контролов и несколькими методами-свойствами.
Как это сделать в принципе - понятно: наваял в design-time базовый фрейм, засунул в репозиторий, а дальше - New Item и включить inherit
вопрос в следующем: а что будет при командной разработке? Т.е. каким макаром импортировать базовый фрейм с dfm с одной машины на другую (или в систему контроля версий)?
Можно ли как-то унаследоваться от фрейма без возни с ресурс-файлами?
REA (2008-03-21 12:25:00) [1]Начет наследования фреймов - бывает оно глючит. Теряет где то свойства предков особенно DB компоненты.
REA (2008-03-21 12:24:00) [2]Мне понадобилось сделать редактируемые формы для своей программы, потому что географическая область применения довольно широка, а в каждом регионе принята своя форма представления инфромации и решаемые задачи тоже отличаются. Так же есть разные режимы работы при которых важно видеть данные в разном виде. Так что грузить формы не из экзешника не кажется мне совсем уже бредовым.
Ega23 (2008-03-20 21:06:00) [3]
> Семеныч (19.03.08 21:20) [28]
Вот аккурат такую штуку реализовали на прошлой работе. Работет в Дагестане. :)
Ega23 (2008-03-20 21:02:00) [4]
> А можно пример оправданной необходимости такой архитектуры
> приложения ?
>
Пример из реальной жизни.
Задача: обновление абстрактнойБД (патч на структуру + добавление некоторых записей в справочники + обновление ХП).
Ограничения: нужно сделать так, чтобы эта "обновлялка" максимально приблизилась к интрепритируему языку (простите за формулировку, но у товарища день рождения и я сейчас пьян).
Вариант решения:
Практически у любой СУБД есть утилита командной строки, с помощью которой можно СУБД "скормить" некий скрипт (или набор скриптов).
Готовим cmd-файл, в который в качестве параметров передаём параметры коннекта.
Соответственно, готовим некий конфигурационный файл в любом доступном для программы формате (сделаны варианты на ini, xml, в данный момент осваивается YAML).
Данный конфигурационный файл регистрируется со своим расширением, к этому расширению привязывается программа.
Файл состоит из следующих "секций":
1. FormCaption
2. Набор параметров. Каждвй параметр:
2.1. Имя.
2.2. Тип параметра.
2.3. Caption параметра
2.4. Default Value
3. Параметризованая командная строка
Программа на входе получает этот файл, выставляет Caption, далее генерит нужное количество фреймов в зависимости от типа.
На кнопке "ОК" висит обработчик, заменяющий параметризованую командную строку введёнными параметрами и далее выполняющий RunAndWait (за функцию в который раз спасибо Игорь Шевченко ©).
После чего выводит результат выполнения и умирает.
ANB (2008-03-20 16:52:00) [5]
> со своим внутренним языком, как это делает та же 1С.
Ну, положим, 1С решила этот вопрос просто - пользует визуал басик и не парится. Только классы для своих примочек написали.
Впрочем, каюсь, я тоже полноценный компилятор поленился писать - за меня оракл работает :)
icWasya (2008-03-20 10:50:00) [6]> Ну это и есть желание странного - одному с рюшечками, другому
> чтобы edit был справа
http://habrahabr.ru/pictures/00/00/01/60/37/picture_12.jpg
Семеныч (2008-03-20 10:01:00) [7]> Игорь Шевченко © (19.03.08 22:45) [29]
> Так бы сразу и сказал
Так я сразу я сказал, что задачи бывают разными. Например, знаю программу, где DFM, можно сказать, и вовсе нет - GUI (притом, довольно навороченный) создается кодом. И для тойзадачи это, видимо, оправдано.
Игорь Шевченко (2008-03-19 22:45:00) [8]Семеныч (19.03.08 21:20) [28]
Так бы сразу и сказал :) В этом случае безусловно имеет смысл хранить.
Семеныч (2008-03-19 21:20:00) [9]> Игорь Шевченко © (19.03.08 21:01) [27]
Форма хранит еще и скрипты: SQL-ные и специальные (на том самом внутреннем языке, о котором ты говорил). SQL-ные исполняются как обычно, а специальные - тем самым движком. На этом внутреннем языке можно писать и обработчики событий, и далеко не только их.
Кроме того, есть визуальный редактор форм (с палитрой компонентов, Инспектором объектов и пр.). Таким образом, без какой-либо перекомпиляции программы можно изменить ее функционал и GUI (вплоть до замены главной формы) чуть ли не полностью. Причем не только под какую-то контору, а хоть персонально под каждого юзера (или роль).
И это под силу IT-шнику, НЕпрограммисту. И не требует Delphi с ее лицензией. И формы в БД - это одна из составляющих, которые в совокупности все это обеспечивают.
:о)
Игорь Шевченко (2008-03-19 21:01:00) [10]Семеныч (19.03.08 20:16) [26]
Я все понимаю, но форма хранит только контролы и обработчики событий этих контролов. Каким образом можно прикрутить рюшечку, если ей ничего не будет соответствовать в коде приложения ?
Семеныч (2008-03-19 20:16:00) [11]> Игорь Шевченко © (19.03.08 20:05) [25]
> Продукты класса ERP хорошо писать на своем движке, со своим
> внутренним языком, как это делает та же 1С.
Угу. Начинаем подбираться к сути вопроса "зачем нужны формы в БД". А если б еще и на на наводящий вопрос кто ответил, то оно и быстрее было бы.
> С какого боку тут формы в базе
Вот как раз с такого, чтобы не "нагромождать в коде компот из отдельных случаев для каждого клиента".
===================================
Игорь, при всех этих десятках клиентов, адаптации под них, прикруткой рюшечек и разной бизнес-логики проект не перекомпилируется вообще. В нем при этом ни один байт не меняется. А группа внедрения и поддержки не разрастается и не требует ни однойлицензии Delphi.
И формы в БД - это одна из составляющих, которые в совокупности это обеспечивают.
Игорь Шевченко (2008-03-19 20:05:00) [12]Семеныч (19.03.08 18:41) [22]
> Продукт класса ERP. Понятное дело, требуется адаптация под
> каждого клиента
> Кто-то просит ввести еще один тип накладной, кому-то нравятся
> рюшечки слева (и он готов за них платить)
Продукты класса ERP хорошо писать на своем движке, со своим внутренним языком, как это делает та же 1С.
> а главное то, что у каждого из них еще и свои особенности
> бизнес-логики.
Тем более, с учетом разной бызнес логики.
С какого боку тут формы в базе - разве что нагромождать в коде компот из отдельных случаев для каждого клиента, что тоже, согласись, не есть хорошо, а главное, сопровождабельно.
Семеныч (2008-03-19 19:29:00) [13]> Джо © (19.03.08 19:15) [23]
> «дорабатывать» все-равно придется.
Не обязательно.
> «перекомпилячить», наверное, это не так уж и сложно
Проблема не в компиляции, а в последующей поддержке нескольких десятков фактически разных программ. Это какая же группа поддержки должна быть по численности? И кто в ней должен работать по уровню? И сколько лицензий Delphi она потребует? И во что все это обойдется по деньгам?
Так что система контроля версий тут не поможет. Наступит момент, когда дальнейшее наращивание объема продаж станет бессмысленным - разросшаяся группа поддержки сожрет всю прибыль.
==========================
Наводящий вопрос - а как решена проблема адаптации и поддержки, например, в 1С? Там ведь даже не десятки, там тысячи клиентов.
Джо (2008-03-19 19:15:00) [14]> [22] Семеныч (19.03.08 18:41)
> > Игорь Шевченко © (19.03.08 15:49) [21]
>
> Можно, конечно.
>
> Продукт класса ERP. Понятное дело, требуется адаптация под
> каждого клиента. Кто-то просит ввести еще один тип накладной,
> кому-то нравятся рюшечки слева (и он готов за них платить)
> , а главное то, что у каждого из них еще и свои особенности
> бизнес-логики.
>
> Таких клиентов несколько десятков, и их количество продолжает
> расти. Что делать? Дорабатывать и перекомпилячивать проект
> под каждого? Или что еще?
Ну дык «дорабатывать» все-равно придется. Только в в предложенном вами варианте придется дорабатывать сущности, которые компилятор не проконтроллирует, т.е., риск невыявленных ошибок повышается. А «перекомпилячить», наверное, это не так уж и сложно, учитывая то, что Делфи компилирует очень быстро :)
А для отделения ветвей текущего продукта давно придумали системы контроля версий :)
Семеныч (2008-03-19 18:41:00) [15]> Игорь Шевченко © (19.03.08 15:49) [21]
Можно, конечно.
Продукт класса ERP. Понятное дело, требуется адаптация под каждого клиента. Кто-то просит ввести еще один тип накладной, кому-то нравятся рюшечки слева (и он готов за них платить), а главное то, что у каждого из них еще и свои особенности бизнес-логики.
Таких клиентов несколько десятков, и их количество продолжает расти. Что делать? Дорабатывать и перекомпилячивать проект под каждого? Или что еще?
Игорь Шевченко (2008-03-19 15:49:00) [16]Семеныч (19.03.08 15:45) [20]
А можно пример оправданной необходимости такой архитектуры приложения ?
Семеныч (2008-03-19 15:45:00) [17]> Игорь Шевченко © (19.03.08 15:11) [19]
>> Если некто чего-то не понимает, то разве это означает, что
>> это что-то плохое или ненужное?
> Это означает, что это странное. См. пост о древнем Китае.
Нет, Игорь. Это означат только то, что некто чего-то не понимает. И больше ничего не означает. Даже если этому некоему оно и кажется странным (что и естественно, раз он не понимает).
А что касается поста древнего Китая, то см. пост об абсолютно безошибочном определителе. Ты же таковым себя не считаешь, верно?
:о)
Игорь Шевченко (2008-03-19 15:11:00) [18]Семеныч (19.03.08 15:03) [18]
> Если руки у программеров заточены криво, то чем виновата
> архитектура приложения?
Кроме дополнительного геморроя разработчикам - ничем. А можно пример оправданной необходимости такой архитектуры приложения ?
> Если некто чего-то не понимает, то разве это означает, что
> это что-то плохое или ненужное?
Это означает, что это странное. См. пост о древнем Китае.
Семеныч (2008-03-19 15:03:00) [19]> Игорь Шевченко © (19.03.08 14:03) [17]
> а во время выполнения вылезают ошибки.
Если руки у программеров заточены криво, то чем виновата архитектура приложения?
> Ну не понимаю я, зачем формы в базе хранить.
Если некто чего-то не понимает, то разве это означает, что это что-то плохое или ненужное?
Игорь Шевченко (2008-03-19 14:03:00) [20]Семеныч (19.03.08 13:32) [16]
> При чем тут переложение обнаружения ошибок?
Я насмотрелся на различные динамические подходы - давайте мы будем загружать, а код у нас будет универсальный для всех случаев. В большинстве своем это приводит именно к тому, что при компиляции все хорошо - как же, код универсальный, а во время выполнения вылезают ошибки.
Наиболее иллюстирующий пример - это обильное использование типа Variant.
Ну не понимаю я, зачем формы в базе хранить. Формы в EXEшнике или в DLL-ях должны жить, самое им там место. Опять же, дабы синхронизацию выполнял компилятор, а не хитрый код во время выполнения.
| |
Страницы: 