| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
хранение пользовательских настроек программы в БД. идеология [D7, IB6.x]
ari_9 © (2007-11-29 12:29:00)клиентской программой пользуются операторы без четкой привязки к рабочим станциям, поэтому хранение настроек в реестре не подходит. кроме того, часть параметров редактировать я разрешаю явно, часть (ну там положение окон, столбцы таблиц на момент закрытия клиента и т.д.) пишу сам. сейчас все реализовано "по-колхозному"
вопрос не в том, как можно сделать - я сам вижу много вариантов, а как сделать правильно
пока предполагаю так:
таблица Parameters
поля
Parameter_ID
Parameter_Parental_ID
Parameter_Name
Parameter_Type
Parameter_Visible
Таблица Users_Parameters
поля
User_ID
Parameter_ID
Parameter_Value - VARCHAR
настройки, используемые мной и не показываемые пользователю: связаны с программными компонентами только по ID, эти ID жестко заданы мной и в коде проекта, и в БД (это несколько напрягает). поле Parameter_Name смысловой нагрузки не несет. загружаю и пишу их из/в Users_Parameters, там где нужно выполнить преобразование типов, беру Parameter_Type из Parameters
настройки, задаваемые пользователем: у пользователя рисую дерево на основе Parameters, куда входят все ветки с Parameter_Visible = 1 и с родительскими Parameter_Visible = 1. редактировать в дереве не позволяю, по клику открываю окошко с параметром (заодно в зависимости от Parameter_Type выставляю маску дбэдита, пишу данные в Users_Parameters)
что не нравится в этой схеме :
1. если како-то парметр у меня задается пользователем не в общем окне настроек, а где-то в других формах (ну, например, последняя строка поиска), то много повторяющегося кода типа параметр с ID равным Tag'у компонета подгрузить, параметр записать ...
2. слишком много данных из БД оказывается внутри кода (ID всех параметров)
3. если понадобится в будущем дать пользователю возможность добавлять свои настройки (а не только редактировать параметры заданных разработчиком), не ясно как это сделать красиво
думаю, такую задачу решали многие, интересно было бы знать к чему пришли в итоге
ari_9 (2007-11-29 20:42:00) [1]Sergey13
А я понял твой 3 пункт именно как создание новых, неизвестных программе настроек, типа "а не заколбасить ли нам зеленую полосу на главной форме".
) нет, не до такой степени клинично, конечно
Anatoly Podgoretsky (2007-11-29 14:47:00) [2]> Sergey13 (29.11.2007 14:41:06) [6]
Я тоже.
И смотрю на это обсуждение и душа протестует.
Sergey13 (2007-11-29 14:41:00) [3]> [5] Anatoly Podgoretsky © (29.11.07 14:24)
Не завидую я тем разработчикам. 8-)
Anatoly Podgoretsky (2007-11-29 14:24:00) [4]> Sergey13 (29.11.2007 13:36:04) [4]
Это тоже можно, только потом разработчик должен разработать обработчик.
Sergey13 (2007-11-29 13:36:00) [5]> [3] ari_9 (29.11.07 13:13)
> естественно, пользователь может добавить пару код-домен.
Ну так это вроде как присваивание значения существующему параметру, про который твоя прога знает. А я понял твой 3 пункт именно как создание новых, неизвестных программе настроек, типа "а не заколбасить ли нам зеленую полосу на главной форме".
ari_9 (2007-11-29 13:13:00) [6]Sergey13
Parameter_CODE это хорошо, да. подумаю. единственный минус, придется его в коде писать руками, а не в дизайнере на тэги развешивать
Это как? А кто их обрабатывать будет? ИИ?
ну, например, есть у меня возможность послать некоторую информацию по смс. и настройки в этом случае это строка вида код (префикс) телефонного номера - почтовый домен, куда отсылается письмо для отправки смс (у нас тут в Украине с разными операторами по-разному). естественно, пользователь может добавить пару код-домен. сейчас это все в отдельной таблице, к общим параметрам отношения не имеющей .... а хочется унификации какой-то
Sergey13 (2007-11-29 12:51:00) [7]Вместо Parameter_ID и Parameter_Name (которые "смысловой нагрузки не несет"), я бы сделал Parameter_CODE и присваивал бы ему осмысленные значения. ИМХО значительно улучшит читаемость кода и не даст самому запутаться.
Sergey13 (2007-11-29 12:45:00) [8]> [0] ari_9 (29.11.07 12:29)
> 3. если понадобится в будущем дать пользователю возможность
> добавлять свои настройки
Это как? А кто их обрабатывать будет? ИИ?
| |
