> что же догда понимать под справочником программы ?


Это тебя надо спросить, что ты под этим понимаешь)


> как реализовать "гибкий справочник"


Какой такой "гибкий" ?)

> User1   (13.05.08 12:30) [39]

Определение "гибкого справочника для работы с некоторыми таблицами в БД" в студию.

Любой "гибкий справочник" подлежит безусловному сожжению в топке

Мож и не любой, но "справочник программы" типа Гандбук гореть будет хорошо)

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

Почему ?

User1   (13.05.08 13:04) [44]

Потому что нет ничего более уродливого и не сопровождабельного, чем "гибкое".

> User1   (13.05.08 13:04) [44]


ИШ хотел сказать, что колоть орехи можно и микроскопом, со всеми вытекающими последствиями.

> User1  (13.05.2008 13:04:44)  [44]

Гнется куда не надо.

> Игорь Шевченко ©   (13.05.08 13:08) [45]

Может быть, но тогда посоветуйте из своего опыта:
Как тогда лучше реализовать справочник n таблиц ?
Помещать на форму DataSource, DataSet, Grid- ы для каждой таблицы ?

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

User1   (13.05.08 13:49) [48]


> Как тогда лучше реализовать справочник n таблиц ?


Наверное как лучше реализовать интерфейс к n справочникам, находящимся в n таблицах ?

Воспользоваться механизмом наследования, например, сделав базовую функциональность в форме-предке, а работу с конкретными справочниками вынести в наследников этой формы, если есть различия. Ну и разумеется на каждый справочник свой DataSet, в датамодуле или в одном кучу или в нескольких, по вкусу. Соответственно, Grid и DataSource будут находиться в предке. Один раз.

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

Размер программы - это последнее, на что стоит обращать внимание при ее разработке.

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

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

Хотелось бы последний вопрос запостить в этой ветке, а именно:


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


Вот этого примеры есть ?

> Игорь Шевченко ©   (13.05.08 13:08) [45]
> User1   (13.05.08 13:04) [44]
>
> Потому что нет ничего более уродливого и не сопровождабельного,
>  чем "гибкое".


Честно говоря слух режет.
У вас был печальный опыт?
Может вы хотели сказать о недокументированном коде?

Гибкостью имеет смысл жертвовать в угоду скорости, но в угоду выразительности не стоит. IMHO.

К
> User1   (13.05.08 14:37) [50]


Наверное как лучше реализовать интерфейс к n справочникам, находящимся в n таблицах ?

> Потому что нет ничего более уродливого и не сопровождабельного,
> чем «гибкое».

Соглдасен.


> Как тогда лучше реализовать справочник n таблиц ?

Просто. Надо сделать n форм для каждого справочника. Причем уи должен учитывать особенноти конкретного справочника.

oxffff ©   (13.05.08 14:38) [51]


> У вас был печальный опыт?
> Может вы хотели сказать о недокументированном коде?


Честно говоря, не совсем понял направление мысли.

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


> Гибкостью имеет смысл жертвовать в угоду скорости, но в
> угоду выразительности не стоит. IMHO.


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

User1   (13.05.08 14:37) [50]


> Вот этого примеры есть ?


А я не знаю твоих задач, как я могу привести примеры ?

> Игорь Шевченко ©   (13.05.08 14:04) [49]
> User1   (13.05.08 13:49) [48]
>
>
> > Как тогда лучше реализовать справочник n таблиц ?
>
>
> Наверное как лучше реализовать интерфейс к n справочникам,
>  находящимся в n таблицах ?
>
> Воспользоваться механизмом наследования, например, сделав
> базовую функциональность в форме-предке, а работу с конкретными
> справочниками вынести в наследников этой формы, если есть
> различия. Ну и разумеется на каждый справочник свой DataSet,
>  в датамодуле или в одном кучу или в нескольких, по вкусу.
>  Соответственно, Grid и DataSource будут находиться в предке.
>  Один раз.


Довольно странное предложение о формах предках.
А что нельзя передавать Caption и Dataset в конструкторе.
Ведь судя по коду ведь ничего не требуется.

>User1   (13.05.08 14:37) [50]

Твоя задача в достижении гибкости заключается в отвязывании от конкретных справочников.

Такой код следует избегать.


> constructor TfHandBook.Create(AOwner: TComponent; ARec:
> THandBook);
> begin
> inherited Create(AOwner);
> FRec := ARec;
> case FRec.ShowType of
>   shbUnknown:
>     begin
>       Close;
>     end;
>   shbRequisite:
>     begin
>       Caption := SRequisite;
>       ds.DataSet := dm.qRequisite;
>     end;
> else
>   begin
>     //Íåèçâåñòíûé âèä âûçûâàåìîãî ñïðàâî÷íèêè.
>   end;
> end;
> end;


А заменить на

constructor TfHandBook.Create(AOwner:Component;ShowType:Integer);
var Rec:THandBook;
begin
rec:=AvailableDicts[ShowType];
rec.BeforeActivate;
if rec.AllowToShow then
     begin
    Caption := rec.caption;
    ds.DataSet := rec.qRequisite;
    end
   else
   Close;
rec.AfterActivate;
end;

RegisterDict( TUniDict.create(caption,Dataset,OnBeforeActivate,OnAfterActivate));

> Игорь Шевченко ©   (13.05.08 14:04) [49]

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

Есть справочник. Пополняется по одной записи в месяц. Пополнять его должен обыкновенный юзер. Как быть?

> User1   (13.05.08 13:49) [48]
>
>


Какая уж тут "гибкость", если ты жестко прописал информацию о таблицах, с которыми будет вестись работа, прямо в коде будущего приложения ?

> Юрий Зотов  (13.05.2008 14:54:56)  [56]

Пополнять может только то кто имеет права на это.

oxffff ©   (13.05.08 14:52) [55]


> RegisterDict( TUniDict.create(caption,Dataset,OnBeforeActivate,
> OnAfterActivate));


Через какое время ты забудешь о том, что делает этот код ?

Юрий Зотов ©   (13.05.08 14:54) [56]


> Есть справочник. Пополняется по одной записи в месяц. Пополнять
> его должен обыкновенный юзер. Как быть?
> <Цитата>
> » удаление...


В разных случаях по-разному, очевидно. Какой юзер, какие данные, и т.д.
Можно раз в месяц выполнить SQL-запрос на вставку записи, например. Можно написать "интерфейс" по образу и подобию, как у автора темы, чтобы раз в месяц юзер с чувством глубокого удовлетворения вводил туда очередную запись.
Можно еще что-нибудь.