Настройки программы

← →
NieL © (2012-11-22 14:42) [0]

Где сейчас модно хранить?

← →
oxffff © (2012-11-22 14:50) [1]

В облаке.

← →
DVM © (2012-11-22 14:50) [2]

Теперь модно хранить все в Моих документах. Некоторые даже туда программы ставят (типа браузерописателей) :)

А вообще всегда "модно" было в реестре. И это единственно правильное место с учетом возможного разворачивания программы в домене. Если есть данные, которые не желательно сохранять в реестр, то их хранят тут:

CSIDL_LOCAL_APPDATA
CSIDL_APPDATA
CSIDL_COMMON_APPDATA

в зависимости от назначения.

Это путь. А формат файла модно XML.

← →
xayam © (2012-11-22 14:50) [3]

> В облаке

только хотел так написать :)

← →
DVM © (2012-11-22 14:51) [4]

> В облаке.

это точно, без интернета теперь ни одна стоящая программа даже пукнуть не может.

← →
xayam © (2012-11-22 14:52) [5]

> без интернета теперь ни одна стоящая программа даже пукнуть
> не может

тогда следующий вопрос: на чем модно писать в облаках? :)

← →
брат Птибурдукова (2012-11-22 14:54) [6]

на арамейском?

← →
xayam © (2012-11-22 15:03) [7]

> на арамейском?

ссылку на компилятор/интерпретатор не подкинете? :)

← →
Dimka Maslov © (2012-11-22 15:08) [8]

В банковской ячейке. Надёжное место. Но дорогое.

А вообще настройки можно хранить где угодно. Главное понимать, что при этом может произойти.

← →
QAZ9 (2012-11-22 15:23) [9]

> И это единственно правильное место с учетом возможного разворачивания
> программы в домене

какбы пользовательские папки тоже в домене присутствуют

← →
DVM © (2012-11-22 15:31) [10]

> QAZ9 (22.11.12 15:23) [9]

параметры реестра удобнее назначать политиками

← →
QAZ9 (2012-11-22 15:33) [11]

> DVM © (22.11.12 15:31) [10]

а каки там политики назначать если храниш в ветке\папке конкретного юзера?

← →
DVM © (2012-11-22 15:35) [12]

> QAZ9 (22.11.12 15:33) [11]

> а каки там политики назначать

Свои. Ты вообще в курсе, что есть политика?

← →
QAZ9 (2012-11-22 15:40) [13]

> Свои

например

← →
DVM © (2012-11-22 15:46) [14]

> QAZ9 (22.11.12 15:40) [13]

> например

Чего например?

Администратор домена может создать свой шаблон, который будет грузить нужные параметры в реестр пользователя при каждом его входе в систему. Фактически ему насильно в реестр будут добавляться значения. Любые.
Соответственно если надо 1000 пользователей в определенной программе сделать определенную настройку централизованно, то им назначается соответтвующая политика, заданная в шаблоне. И все. Далее программы при запуске читают эти значения через реестр.

← →
niel © (2012-11-22 15:58) [15]

Облако сразу отпадает, не вижу смысла.

Забыл добавить программа будет кросс-платформенная (firemonkey), так что реестр тоже не подойдет.

← →
DVM © (2012-11-22 16:16) [16]

> niel © (22.11.12 15:58) [15]

> Забыл добавить программа будет кросс-платформенная (firemonkey),
> так что реестр тоже не подойдет.

Я бы на твоем месте создал свой класс с методами, похожими на TIniFile или TRegistry для записи целых чисел, строк и т.д. У класса сделать настройки, где он должен хранить инфу, например:

TConfigLocation = ( cloAppDir, // Папка программы cloLocalAppData, // CSIDL_LOCAL_APPDATA cloRoamingAppData, // CSIDL_APPDATA cloAllUserAppData, // CSIDL_COMMON_APPDATA cloRegistryCurUser, // HKEY_CURRENT_USER\Software cloRegistryAllUsers // HKEY_LOCAL_MACHINE\Software );

Сделать настройку формата хранения:

TConfigStorageType = (
cstXml, // Хранить настройки в XML файле
cstINI, // Хранить настройки в INI файле
cstRegistry); // Хранить настройки в реестре

Также предусмотреть поля :

FAuthor: string;
FProductName: string;
FProductVersion: string;
FProductComponentName: string;

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

Так как интерфейс будет универсальным, то для программы будет все равно куда сохранять и откуда читать конфигурацию, это будет опеределяться настройками класса. Если добавить директивы условной компиляции типа {$IFDEF UNIX} то можно такой класс адаптировать и для других ОС, но используя их возможности по хранению пользовательских настроек (база SQLITE, файлы, и т.д.) и определению местоположения где хранить.

Создай один раз и используй потом многократно.

← →
знайка (2012-11-22 16:27) [17]

А про какие настройки вопрос?

← →
DVM © (2012-11-22 16:31) [18]

> знайка (22.11.12 16:27) [17]
> А про какие настройки вопрос?

а какие есть варианты?

← →
знайка (2012-11-22 16:38) [19]

Да какие угодно.
Ну например настройки ползователя по системе скоторый находится в базе данных, и которые хотел бы видеть вне зависимости от доменов (сидя дома...)
Тут никакие реестры не помогут тут в базе и складывать.

← →
niel © (2012-11-22 16:38) [20]

> DVM © (22.11.12 16:16) [16]

Отличный совет, спасибо, Так и сделаю.

← →
Jeer © (2012-11-22 16:41) [21]

> NieL © (22.11.12 14:42)
>
> Где сейчас модно хранить?

Отвечу оригинально - нигде.
Даже в голове - ни-ни.

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

← →
Пит (2012-11-22 16:48) [22]

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

а кто-то реально так делает? на практике?

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

← →
DVM © (2012-11-22 16:54) [23]

> Пит (22.11.12 16:48) [22]

> а кто-то реально так делает? на практике?

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

>
> Обычно корпоративное ПО работает с БД,

Хорошо, есть 1000 клиентов у них надо поменять настройки для подключения к БД. Если настройки лежат в реестре, то это делается элементарно, если в INI то будут сложности.

← →
DVM © (2012-11-22 17:01) [24]

> знайка (22.11.12 16:38) [19]
> Тут никакие реестры не помогут тут в базе и складывать.

Настройки подключения к базе где хранить ? :)

← →
Пит (2012-11-22 17:04) [25]

> Хорошо, есть 1000 клиентов у них надо поменять настройки
> для подключения к БД. Если настройки лежат в реестре, то
> это делается элементарно, если в INI то будут сложности.

а этим как раз занимается специализированное ПО по развертыванию систем. Я не представляю как можно жить без такого ПО, если у тебя 1000+ клиентов. У нас вот используется Altiris.
И параметр в реестре в контексте некой настройки "Ключ=Значение" это всего лишь капля в море.

← →
знайка (2012-11-22 17:11) [26]

> Настройки подключения к базе где хранить ? :)
Я как вы заметили сразу и акцентировал вопрос на том про какие настройки речь. ага?

← →
DVM © (2012-11-22 17:13) [27]

> Пит (22.11.12 17:04) [25]

> а этим как раз занимается специализированное ПО по развертыванию
> систем. Я не представляю как можно жить без такого ПО, если
> у тебя 1000+ клиентов.

Да в Windows есть все необходимое для управления сетями любого размера. Вся эта технология, все вместе вроде бы носит название IntelliMirror.
Сторонние инструменты просто многие вещи позволяют делать быстрее и удобнее.

← →
БарЛог © (2012-11-22 17:16) [28]

Пит (22.11.12 16:48) [22]

> а кто-то реально так делает? на практике?

Делает. Для чужого ПО.
Те же настройки браузера, например.

Пит (22.11.12 17:04) [25]

> а этим как раз занимается специализированное ПО по развертыванию систем. Я не > представляю как можно жить без такого ПО, если у тебя 1000+ клиентов.

За ПО надо доплачивать. По мелочи - можно деплоить через те же групповые политики.

← →
DVM © (2012-11-22 17:17) [29]

> знайка (22.11.12 17:11) [26]

> Я как вы заметили сразу и акцентировал вопрос на том про
> какие настройки речь. ага?
>
>

Имхо вы смешиваете два понятия. Есть настройки программы (они почти все ложатся в реестр) и есть данные программы. Данные ложатся либо в спец папки либо в базу, а сама база либо в спец папку, либо в сети.
Никто конечно не запрещает хранить в базе все.

← →
знайка (2012-11-22 17:20) [30]

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

← →
MsGuns © (2012-11-22 17:21) [31]

Удалено модератором

← →
БарЛог © (2012-11-22 17:24) [32]

MsGuns © (22.11.12 17:21) [31]

> В голове.

Пользовательской? :)
Через политики внедрять :)

← →
DVM © (2012-11-22 17:26) [33]

> знайка (22.11.12 17:20) [30]

> а если я хочу со своего телефона посмотреть, что у меня
> творится в системе, то как реестр этому поможет?

Опять путаете данные и настройки. В реестре нечего смотреть с телефона. В телефоне свои настройки. С телефона смотреть надо данные, а вот они то и могут лежать в базе.
Кстати настройки на телефон тоже могу быть в домене получены централизованно (например, для Blackberry через политики BES, для Windows Phone через ActiveSync кажется)

Удалено модератором

> С телефона смотреть надо данные, а вот они то и могут лежать
> в базе.

настройки вообще-то тоже являются данными

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

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

> Игорь Шевченко © (22.11.12 17:38) [36]

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

> MsGuns © (22.11.12 17:41) [37]
> Вот нравится это продвинутое "хранить логин и пасворд в
> настроечках".

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

DVM © (22.11.12 18:31) [41]

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

> niel © (22.11.12 15:58) [15]
> Облако сразу отпадает, не вижу смысла.
>
> Забыл добавить программа будет кросс-платформенная (firemonkey),
> так что реестр тоже не подойдет.

с какого перепугу? пишешь общий абстрактный класс настроек, методы сохранения/чтения перекрываешь директивами компилятора. Под виндой пусть в реестр пишет и под гномом (там есть аналог), под убунтой/маком конфиг файл в /etc,

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

DVM © (22.11.12 19:14) [44]

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

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

← →
han_malign (2012-11-23 09:55) [46]

> cloRegistryCurUser, // HKEY_CURRENT_USER\Software
> cloRegistryAllUsers // HKEY_LOCAL_MACHINE\Software

- еще одного не хватает: в W7 - HKCU - уже roaming, а HKLM - мандата требует...
All registry entries in HKEY_CURRENT_USER except those under HKEY_CURRENT_USER\Software\Classes are included in the per-user registry portion of a roaming user profile. To exclude other entries from a roaming user profile, store them in HKEY_CURRENT_USER_LOCAL_SETTINGS.

> han_malign (23.11.12 09:55) [46]

> HKEY_CURRENT_USER_LOCAL_SETTINGS.

Да, верно, это аналог CSIDL_LOCAL_APPDATA но применительно к реестру.

← →
Аббат Пиккола (2012-11-23 13:31) [48]

Я часть храню в ini (списки баз и строки подключения), часть в реестре (положения, размеры окон и прочая хрень, зависящая от размеров мониторов рабочих мест и т.п.), а часть - в базе данных (настройки под конкретных юзеров, которые они с любого компа хотели бы иметь одинаковыми + привилегии доступа всяческие, естественно там же - в базе).

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

1. Удобно
2. Относительно безопасно (защита от дурака)
3. Не мешало сразу начать работать ит быстро натйи причины проблем, даже если что-то где-то не совсем правильно.

Настройки программы Найти похожие ветки