Что придёт на смену xorg.conf?

>Открой для себя подсветку тегов и автовыравнивание.

Допустим, при сохранении конфига он повредился.. Куда пойдёт твоя подсветка и автовыравнивание? ;)

>>Открой для себя подсветку тегов и автовыравнивание.

>Допустим, при сохранении конфига он повредился.. Куда пойдёт твоя подсветка и автовыравнивание? ;)

Кто повредился?

> vs_I_Config* config = GlobalConfig

VSL_Config? O_o
Ъ VSL_Config должен быть на лиспе, на худой конец -- на Схеме :)

> VSL_Config? O_o

не VSL_Config, а vs_I_Config, vs - приставка от проекта, I - интерфейсный класс

>> Допустим, при сохранении конфига он повредился.. Куда пойдёт твоя подсветка и автовыравнивание? ;)

> Кто повредился?

да конфиг то конечно, причем "пойдёт" не только подсветка и автовыравнивание, а и весь конфиг целиком( причем всего-лишь из-за одного недостающего символа - красота :) )

> и когда обновляется моя программа, если идет попытка к чтению этого параметра, но его еще нет в конфиге, то будет использоваться дефолтное значение( true ), как только пользователь изменит его в диалоге настройки( или моя программа это сделает ) он автоматом ляжет в старый конфиг( это все делает wx, а я образно говоря вообще не должен ничего знать про файл конфига )

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

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

А с другой стороны - с глобальным SQL хранилищем можно было бы делать более интеллектуальные вещи. Вот у вас дефолтное значение = true, а почему? Можно же заселектить из базы предпочтения пользователя в отношении других программ и в случа, если обнаружится, что обычно пользователь избегает использования автокомплита или там всплывающих хинтов (кстати отдельные конфиги для одного и того же юзера при удаленном и локальном доступе возможны?) - то и дефолтить настройки в соответствии с предпочтениями юзера, а не вашими. Да ещё вытряхнуть из настроек других приложений аккаунты для доступа к базе, которыми пользуется юзер, да ещё позволить админу или юзеру кастомизировать ваши SQL-запросы что бы они могли подгонять их под свою специфику..

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

>С одной стороны это, возможно, не очень нравится любителям ини-файлов, привыкшим, что в конфиге перечислены все опции

Эээ.. Мы сейчас о какой операционке говорим? :)

>>> Допустим, при сохранении конфига он повредился.. Куда пойдёт твоя подсветка и автовыравнивание? ;)

>> Кто повредился?

>да конфиг то конечно, причем "пойдёт" не только подсветка и автовыравнивание, а и весь конфиг целиком( причем всего-лишь из-за одного недостающего символа - красота :) )

Любителей С++ вроде тебя проблемы с "недостающим символом" не останавливают. А в XML грамматика вполне себе context-free.

> С одной стороны это, возможно, не очень нравится любителям ини-файлов, привыкшим, что в конфиге перечислены все опции

легко :)

void CheckConfig( void )
{
vs_I_Config* config = GlobalConfig;

if( !config->Exist( _T("/SQLEditor/AutoComplete") )
config->Write( _T("/SQLEditor/AutoComplete"), true );

....
}

> Вот у вас дефолтное значение = true, а почему? Можно же заселектить из базы предпочтения пользователя

ну это уж очень круто и в принципе от способа хранения конфигов не зависит( т.е. можно сделать везде, хотя конечно тут SQL поможет один раз сэкономить время )

> кстати отдельные конфиги для одного и того же юзера при удаленном и локальном доступе возможны?

очень легко реализуется

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

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

тут, imho - "испорченный телефон". первый, IMO - про разметку. второй - про реализацию, означенных фич - в редакторе(те - вне конфига).

p.s. если я не путаю.

> А с другой стороны - с глобальным SQL хранилищем можно было бы делать более интеллектуальные вещи.

например, инъекции.

>> А с другой стороны - с глобальным SQL хранилищем можно было бы делать более интеллектуальные вещи.

>например, инъекции.

Если у девушке на попе прыщик это не значит что ее нельзя трахать.

> Если у девушке на попе прыщик это не значит что ее нельзя трахать.

А можно? Правда можно!?

> О_о. Херасе флуд. Это наверное рекорд в истории ЛОРа? Или есть крупнее?

"Фраза о Лиспе" вроде длинее.

> Если у девушке на попе прыщик это не значит что ее нельзя трахать.

Цыц! Это же тайна, строго хранимая производителями женской косметики.

+1 или "про Баяна творение" тред.

ака Эльбрус

bump

> Если не нравится избитый пример про sendmail.cf, 
> могу предоставить другой: конфиг банкомата или платёжного терминала, представленной как машина состояний. Его в дерево не сохранишь из-за наличия циклов.

Читал топик но не стерпел и решил ответить. У нас в системе (написанной на java) набор состояний хранится именно в xml-конфиге. 
Там же описаны правила перехода между состояниями. И циклы вполне естественны.

<root>
 <state id="state1">
  <onSave move="state2"/>
  <onError move="endState"/>
 </state>

 <state id="state2">
   <onChange move="state1"/>
   <onError move="endState"/>
 </state>

  ....

</root>

И цикл имеется ;)