сохранение настроек

← →
stenfit (2010-12-06 18:50) [0]

актуально ли сейчас хранить настройки в ini-файлах?

← →
xayam © (2010-12-06 18:55) [1]

если только ini удаленный :)
у себя уже никто не хранит :)

← →
Anatoly Podgoretsky © (2010-12-06 19:41) [2]

> stenfit (06.12.2010 18:50:00) [0]

Если данные простые то можно.

← →
Ega23 © (2010-12-06 20:00) [3]

Хранилище как хранилище, имеет свои плюсы и свои минусы.

← →
Dimka Maslov © (2010-12-06 20:05) [4]

актуально их хранить в папке с данными пользователя. А формат - вторичен.

← →
Kerk © (2010-12-07 01:18) [5]

В этом сезоне актуально хранить настройки в реестре.

← →
Германн © (2010-12-07 01:26) [6]

На вкус и цвет...

← →
Германн © (2010-12-07 01:32) [7]

> Dimka Maslov © (06.12.10 20:05) [4]
>
> актуально их хранить в папке с данными пользователя.

Пожалуй это единственное неудобство в использовании ини-файлов сейчас.

← →
Eraser © (2010-12-07 01:49) [8]

> [0] stenfit (06.12.10 18:50)

актуально хранить в XML, т.к. будет проще внедрять кроссплатформенность в будущем.

← →
Германн © (2010-12-07 02:20) [9]

> Eraser © (07.12.10 01:49) [8]

И та же проблема останется с тем, где этот XML хранить.

<offtop>
Кстати мне почему-то аббревиатура XML уже давно вызывает ассоциации с неким "просторечивым" нашим словом. Нужно только добавить две гласные. :)
</offtop>

P.S. Если я перешел границы допустимого оффтопа, модераторы удалят это сообщение.
P.P.S.
Данное слово найдено только в
"С.И. Ожегов, Н.Ю. Шведова
Толковый словарь русского языка"
Во всех прочих уважаемых словарях его нет.

← →
Eraser © (2010-12-07 03:07) [10]

> [9] Германн © (07.12.10 02:20)

> И та же проблема останется с тем, где этот XML хранить.

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

← →
Германн © (2010-12-07 03:31) [11]

> Eraser © (07.12.10 03:07) [10]
>
> > [9] Германн © (07.12.10 02:20)
>
>
> > И та же проблема останется с тем, где этот XML хранить.
>
>
> никакой проблемы нет

Ты забыл про суть ini-файлов! Эти файлы в старых версиях Винды хранились там, (как правило), где их Винда легко находила. И таких мест было много, где винда искала, находила и позволяла изменять эти файлы.
Насколько я знаю, сейчас (Vista + 7) таких мест просто нет.
Т.е. всё что мы можем, мы и должны сами реализововать.

> хранить в специальном каталоге, предназначеном для файлов
> настроек.

А это какой каталог?
А ну да. Личный каталог пользователя или общий каталог всех пользователей.

Тогда я голосую за файл *.dat

← →
Eraser © (2010-12-07 04:06) [12]

> А ну да. Личный каталог пользователя или общий каталог всех
> пользователей.
>
> Тогда я голосую за файл *.dat

не вижу логики. хотя какая разница, какое расширение.

> Ты забыл про суть ini-файлов!

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

← →
Германн © (2010-12-07 04:20) [13]

> не вижу логики. хотя какая разница, какое расширение.

А тут логика простая. Для ini-файлов в Windows есть/был встроенный механизм работы с ними. Вспомни, что изначально, для ini-файлов достаточно было указать только имя файла (без пути к нему).

> суть у них одна - хранить настройки в текстовом файле

Это только одна из особенностей. Вспомни средства Дельфи для "особой" работы с такими файлами.

Дык, мне тогда проще формировать свой файл настроек, не оглядываясь на ОС.

← →
Eraser © (2010-12-07 04:29) [14]

> [13] Германн © (07.12.10 04:20)

> Дык, мне тогда проще формировать свой файл настроек, не
> оглядываясь на ОС.

я про это же. только зачем изобретать велосипед, т.е. свой формат? есть xml, для работы с ним есть удобные библиотеки практически на всех ЯП.

вообще в связке Delphi + Windows вижу 2 способа, которые имеет смысл использовать для хранения настроек - XML и стандартный механизм сериализации компонентов. каждый из способов имеет свои явные плюсы и явные же минусы. другой вопрос - где хранить эти настройки. здесь практически без вариантов - либо реестр, либо файлы (с специальном, отведенном системой каталоге).

← →
Германн © (2010-12-07 04:30) [15]

<offtop>
Ну и в добавок.
Преклоняясь пред мудростью авторов Windows, я всё же сомневаюсь, что они смогут реализовать свой реестр так, чтобы эта их псевдо-БД работала и через 10 лет.
</offtop>

← →
Германн © (2010-12-07 04:36) [16]

> Eraser © (07.12.10 04:29) [14]
>
> > [13] Германн © (07.12.10 04:20)
>
>
> > Дык, мне тогда проще формировать свой файл настроек, не
> > оглядываясь на ОС.
>
> я про это же. только зачем изобретать велосипед, т.е. свой
> формат? есть xml

Ну Леш, я ещё не достиг пока такого уровня, чтобы набор сырых записей и простых полей формировать в XML. Тем более, что у меня нет денег, чтобы нанять в качестве учителя Медвежонка. :)

← →
Eraser © (2010-12-07 04:40) [17]

> [16] Германн © (07.12.10 04:36)

> ещё не достиг пока такого уровня, чтобы набор сырых записей
> и простых полей формировать в XML

набор сырых записей или полей думаю лучше хранить в SQL формате ;-)

← →
Германн © (2010-12-07 04:49) [18]

> Eraser © (07.12.10 04:40) [17]
>
> > [16] Германн © (07.12.10 04:36)
>
>
> > ещё не достиг пока такого уровня, чтобы набор сырых записей
> > и простых полей формировать в XML
>
> набор сырых записей или полей думаю лучше хранить в SQL
> формате ;-)

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

← →
Ega23 © (2010-12-07 07:20) [19]

> а сейчас времена другие.

Какие?

← →
han_malign (2010-12-07 13:26) [20]

> актуально хранить в XML, т.к. будет проще внедрять кроссплатформенность в будущем.

- то есть "[valume1]\r\nparam1=value1\r\n", с тупым линейным парсером - ни разу не кросс-платформенно?

Чтоб быть рядах кросс-носцев надо - на пару десятков слабо-связных параметров - обязательно добавить сотню дополнительных символов, затем ради экономии десятка байт и чистоты DOM структуры удалить все незначащие линейные пробелы и выяснить в каких случаях этот DOM-провайдер не падает???
А... - чуть не забыл, еще обязательно x-path прикрутить, иначе совсем за деревенщину неумытую сойдешь...

← →
Eraser © (2010-12-07 14:06) [21]

> [19] Ega23 © (07.12.10 07:20)

сейчас MS не рекомендует хранить настройки в системных каталогах, а windows, в ряде случаев, это и не позволяет делать.

> [20] han_malign (07.12.10 13:26)

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

← →
sniknik © (2010-12-07 14:26) [22]

> нравится технология 30 летней давности
нравится не нравится, какая разница? во многих случаях ini удобнее, так же как хранение его рядом с программой а не "в местах для этого отведенных".
и что с пользователем не делай, он все одно пытается в настройки блокнотом влезть (т.е. xml ему не будет так уж удобен).
ну например у нас практикуется установка программы на сервере, с запуском оттуда, т.е. если класть настройки в реестр/каталог пользователя/... то придется настраивать программу на каждой машине. что для админов напряжно.
а так, настройки программы в ini рядом, настройки интерфейса(/юзерские) в базе и не зависят от того на какой машине юзер прогу запускает. и все довольны.

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

← →
DiamondShark © (2010-12-07 14:47) [23]

> нравится технология 30 летней давности

А кодировке ASCII вообще пятьдесят лет. Фтопку её!
А паскалю сорок. Только старые маразматики пишут на паскале.
Ах, да. Объектно-ориентированному программированию тоже под сорок. FFFFFFFFUUUUUUUUUUUUUUU!!!!!!!!!!!!!!!!!!!!!!!

Как же маркетоиды людям моск загадили...

← →
DiamondShark © (2010-12-07 14:50) [24]

> ну например у нас практикуется установка программы на сервере,
> с запуском оттуда, т.е. если класть настройки в реестр/каталог
> пользователя/... то придется настраивать программу на каждой
> машине. что для админов напряжно.

Дикие у вас какие-то админы. Видимо, от слов active directory и roaming profile шарахаются, нервно крестясь и сплёвывая через плечо.

← →
Маркетоид (2010-12-07 14:55) [25]

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

Считав из ини значение, ты получаешь всего лишь значение.

Найдя в xml узел, ты получаешь как само значение(я), так и структуру, которую можно использовать в качестве параметров процедур/функций.

Один раз считал, затем передал куда-то. Обработал, сохранил в нее же (структуру) передал дальше если надо.
В конце вызвал save и все.

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

Романтика!

← →
Ega23 © (2010-12-07 14:55) [26]

> сейчас MS не рекомендует хранить настройки в системных каталогах,
> а windows, в ряде случаев, это и не позволяет делать.

А кто говорит про системный каталог?

← →
Jeer © (2010-12-07 16:07) [27]

> Романтика!

Бред.

← →
Маркетоид (2010-12-07 16:16) [28]

Бред.

Давай так.
Допустим есть приложение работающее с БД.
Серверов несколько.
Требуется хранить настройки подключения ко всем серверам и ид последнего сервера (с которым работали последний раз)

Ты демонстрируешь свой вариант, я демонстрирую свой.

И предметно сравним у кого что вышло.

← →
han_malign (2010-12-07 16:31) [29]

> Допустим есть приложение работающее с БД.
> Серверов несколько.
> Требуется хранить настройки подключения ко всем серверам
> и ид последнего сервера (с которым работали последний раз)

> Работая с кластером получаешь неоспоримую выгоду, если
> конечно вкурил всю мощь и гибкость которая доступна тебе.
>
>
> Считав из xml значение, ты получаешь всего лишь значение.

← →
Маркетоид (2010-12-07 16:34) [30]

и это все аргументы?

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

Ещё сильно теряешь в зависимостях. А значит и в размере исполнимого файла и занимаемой памяти! Это не по взрослому !

> DiamondShark © (07.12.10 14:50) [24]

Вот и я про то же.

← →
Маркетоид (2010-12-07 16:42) [32]

Вот и я про то же.

Пока что (по факту) вы тупо зассали представить свой вариант кода.
Перескочив на какой-то "кластер".

А посему досвидос.
Дискутировать с вами в таком ключе совершенно неинтересно.

> Работая с xml через dom

Какую задачу-то решаем?
А решаем мы задачу хранить некоторые параметры приложения в некотором внешнем файле. При этом не просто хранить, а иметь возможность их настроить вручную. Иначе обычный бинарный стрим отлично подходит.
Простому пользователю гораздо нагляднее редактировать ini, чем xml. Как минимум в том, что в ini ошибиться гораздо сложнее.

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

А какая, собственно, разница в том, как объект десериализуется?
TMyObject.LoadFromStream(Stream: TStream); TMyObject.LoadFromIni(ini: TIniFile; Section: string); TMyObject.LoadfromXML(Node: IXMLNode);
Один хрен любой из этих трёх методов надо реализовывать (а то и все разом).

Вот если бы каждый объект, начиная с TObject, наследовал бы LoadfromXML(Node: IXMLNode), то наверное какая-то соль в этом была бы.
А так - фигня полная. Холивар a-la Windows vs. Linux

Крылья, ноги... главное - хвост!

Задачи вообще разные бывают. И нередко XML применять неоправданно.
Так-то то, что XML дает больше возможностей, чем INI, очевидно.
Но продолжая логику можно заявить, что настройки нужно хранить в базе Oracle, потому что [... перечисление возможностей, которые не даст XML ...]

> А посему досвидос.

Аревуар. Спасибо, что так быстро слиняли.

← →
Маркетоид (2010-12-07 16:52) [36]

Вот если бы каждый объект, начиная с TObject, наследовал бы LoadfromXML(Node: IXMLNode),

Нет, вы совершенно не поняли меня.
Мечта иметь методы загрузки/сохранения в хмл начиная с tobject - она вообще не характерна тем, кто умеет работать с хмл

Мне это тоже не нужно, просто потому что мне не нужен сам объект TMyObject.

Понимаете?

Не нужен объект и не нужны методы ненужного объекта.

В этом вся фишка.

Если работаешь с Ruby, то имеет смысл сериализовать объект в YAML
Если работаешь с JavaScript - в JSON
XML - типа универсальное описание (но перегруженное и нужен DOM).
Ini - просто, но не поддерживает древовидность (точнее, она достигается ректальным способом).

← →
Маркетоид (2010-12-07 16:56) [38]

Внутри хмл есть некий узел, который является рутом некой сущности.
Так вот сам этот дом узел - и есть замена тому самому TMyObject"у у которого вы так мечтаете иметь методы LoadFromXML/SaveToXML

Я беру этот узел и читаю/пишу из него данные.
Я беру и передаю его параметром куда мне надо.
И все.

Никаких tmyobject и никакой кастомной сериализации.
Ложки нет!

>
> Ini - просто, но не поддерживает древовидность

Все достигается элементарным способом, если не приучать себя думать ректально.

← →
Маркетоид (2010-12-07 16:58) [40]

Если работаешь с Ruby, то имеет смысл сериализовать объект в YAML
Если работаешь с JavaScript - в JSON

А я работаю с Delphi и ничего не сериализую если надо повзаимодействовать с внешним миром.

Не сериализую потому что у меня нечего сериализовать.
У меня все уже в xml

сохранение настроек Найти похожие ветки