Зачем хранить конф файлы в XML ?!

Я вот тоже не понимаю. Парсили раньше .conf и никто не плакал. А теперь вдруг — сложно парсить, ололо.

Радостно переходим на хмл, а когда вдруг нужно его ручками подправить:

<недоумение><уныние><кровь><тоска><ненависть><злость><агрессия><печаль>Нет</печаль></агрессия></злость></ненависть></тоска></кровь></уныние></недоумение>

Не понимаю.

Дак я давно говорю, что INI идеален. Надо только сделать INI с уровнями вложенности, если уж их так не хватает.

Многоуровневый INI представляется мне как-то так:

[Object]

name = Object 1

	[Position]
	x = 10
	y = 20
	z = 30
	
	[Rotation]
	x = 0.1
	y = 0.2
	z = 0.3

active = true

надо, но не так же уродливо:

"Me, myself & <I>"

В чём уродливость? Не пиши текстовые данные в атрибуты и ничего кроме < > и & экранировать не надо. Няшно и красиво экранирование выглядеть не будет нигде. Кавычки ты вот экранировал для красного словца.

ini действительно хорош во многом.

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

Тёплые ламповые \" куда няшнее же.

\-экранирование это вообще ССЗБ какое-то. Фу.

дваждую

Просто это модно и глупо. Да.

Если «глупая мода» царит более 10 лет, то это или не мода, или не глупая.

представляю, как бы выглядели рекэкспы с экранированием в стиле xml :D

Регэкспы и так уже выглядят как write-only говно, не надо ничего представлять :}

Выглядит как whitespace^Wпитон.

Вот, в json получилось в 2 раза меньше негатива, чем в xml.

Потому что там ты напихал в строку и не смог осилить её прочтение, а тут JSON разжёван в виде дерева? Ага, ага. И это только начало. Потом ты начнёшь туда добавлять и проставлять запятые получится лапша :3

Кавычки, кстати, тоже «лишние символы». Ай-яй-яй!

Выглядит как whitespace^Wпитон.

Из питона табы и позаимствовал. Но ведь приятно выглядит, без излишеств.

Комментарий из рубрики «несмываемый стыд».

>dmitry_malikov

Чья б корова мычала :}

зато читать очень %уево

yaml !

java-проблемы :( Парсятся удобно, а то что это не userfriendly разрабов не волнует. Я бы какой-нить json предпочёл....

Если «глупая мода» царит более 10 лет

миллионы мух не могут ошибаться, да

Он всё равно правится в vim'е пару раз за год

угу, когда адмнишь локалхост

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

<section>
    <name>Name of smth</name>
    <properties>
         <p1>111111</p1>
         <p2>111111</p2>
    </properties>
</section>

[section]
name=Name of smth
properties\p1=11111
properties\p2=22222
...

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

properties\p1=11111

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

(section Name (property1 val1) (property2 val2))

А я не админ, я девелопер, так что админю я свой локалхост(ноутбук) и пачку тестовых виртуалок.

XML
конфиг в нём приятен глазу

У меня жир аж с монитора капает.

Предлагаю сразу пихать программу на жабе вместо конфига, чего уж!

Это в стиле емаксовых алистов.

YAML FTW!

Жаба тяжёлая слишком, а вот схема ничего так. А в случае динамических языков имхо лучше на самом языке конфиг и делать.

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

Лучше вообще без вложенных параметров, чем как в хмл.

Предложите более удобную альтернативу.

миллионы мух не могут ошибаться, да

Не могут. Ошибаться может тот, кто мухам свой вкус навязывает.

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

properties\p1=11111
name=Name of smth
properties\p2=22222

Многоуровневый INI представляется мне как-то так:

Вложенность отступами делается? Питон головного мозга?

xml - кака, но ничего лучше для структурированных конфигов не придумали.
у xml'я хотя бы валидация есть, а у остальных? В программе ручками проверять? Угу, спасибо, вот явно некуда время девать, явно на написание лишнего кода придётся тратить.

Хотя я как-то для Явы написал свой велосипед, который по сути является описанием POJO и отлично мапится в бины, но с плюсами, а тем паче с C, такое не пройдёт.

даже самый простой конфиг в нём приятен глазу и выглядит солидно и надёжно.

...и глобально!

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

в случае динамических языков имхо лучше на самом языке конфиг и делать.

И термин «исполнение произвольного кода» приобритет новое значение.

\-экранирование это вообще ССЗБ какое-то. Фу.

какой забавный детектор-тред. бугага.

А то\\\\\\\\\\\\\\\\\\\\\\

Ты еще макось не видел :)

Не понимаю.

все понятно, все красиво и читабельно, что в текстовом:

<key>IOKitPersonalities</key>
	<dict>
		<key>VoodooHDA</key>
		<dict>
			<key>CFBundleIdentifier</key>
			<string>org.voodoo.driver.VoodooHDA</string>
			<key>IOClass</key>
			<string>VoodooHDADevice</string>
			<key>IOMatchCategory</key>
			<string>VoodooHDADevice</string>
			<key>IOPCIClassMatch</key>
			<string>0x04030000&amp;0xffff0000</string>
			<key>IOProviderClass</key>
			<string>IOPCIDevice</string>
			<key>IOUserClientClass</key>
			<string>VoodooHDAUserClient</string>
			<key>InhibitCache</key>
			<true/>
			<key>MixerValues</key>
			<dict>
				<key>iGain</key>
				<string>90</string>
				<key>iMix</key>
				<string>0</string>
			</dict>
			<key>NodesToPatch</key>
			<array/>
			<key>Noise</key>
			<integer>2</integer>
			<key>Vectorize</key>
			<false/>
			<key>VoodooHDAEnableHalfMicVolumeFix</key>
			<false/>
			<key>VoodooHDAEnableHalfVolumeFix</key>
			<false/>
			<key>VoodooHDAEnableMuteFix</key>
			<false/>
			<key>VoodooHDAEnableVolumeChangeFix</key>
			<false/>
			<key>VoodooHDAVerboseLevel</key>
			<integer>0</integer>
		</dict>
	</dict>

что в графическом виде

Это какой-то негодный XML.