config in PHP vs config in XML

[SiMM]

Автор оригинала: 2NetFly
а применение xml конфигурационного файла позволяет мне использовать один и тот же конфиг в обеих системах.

Скорее, позволяет использовать встроенные средства языков или готовые библиотеки для его парсинга.

 

[StUV]

"выбор формата конфигурационного файла зависит исключительно от требований (сложности решаемой задачи) и субъективных предпочтений".

все упирается в эту фразу: о субъективных предпочтениях ты уже все объяснил, а вот о первой части - ни слова....

 

[2NetFly]

Господа, вы видимо не так меня поняли. Перечитайте дискуссию.

Каков был вопрос:
Почему бы сразу не описывать конфигурационный файл в формате кэша?

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

 

[Макс]

Фанат
ты понимаешь конфиг как один/два файла с настройками.

Но есть такие framework-и (например Prado - недавний победитель Zend). Где на каждый компонент свой XML-файл.
Под компонентами там подразумеваются такие классы как
TCheckbox , TImage, THyperLink и т.д.
В стандартном фреймворке их около 20.
А значит надо делать парсинг 10-20 xml-файлов при каждом запросе юзера.
Такое кеширование необязательно, но один из путей оптимизации скрипта.

Вопрсы типа "Зачем писать такие framework-и? Зачем их использовать" - это не ко мне.

 

[SiMM]

Автор оригинала: 2NetFly
Каков был вопрос:
Почему бы сразу не описывать конфигурационный файл в формате кэша?

Это был один из вопросов

Я утверждал только то, что хранение конфига в структуре языка - это не лучшее решение.

Возможно, были неверно поняты - уж больно сильно напирали на xml

 

[2NetFly]

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

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

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

 

[Макс]

Автор оригинала: SiMM
2NetFly, а я не понимаю, чем ini хуже xml

ini не хуже XML.

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

ini позволяет лишь 2 уровня вложенности. Либо можно придумывать свой парсер для ini который бы обрабатывал параметры типа :

[form]
field.login = text
filed.login.validator = check_login
...

 

[wrapper]

SiMM

>Почему бы сразу не описывать конфигурационный файл в формате кэша?

ИМХО это очевидно, кому нет, обосную:

1) Формат конфига будь то .ini или .xml более удобочитаемый

2) Для XML конфига можно сделать валидацию ( DTD, XML схема ), как вы будете валидировать захардкоденый кеш?

3) Есть разработчик некоего фреймворка, маппера, etc. а есть его пользователь, программист который используетт его в своем проекте. Зачем ему вообще знать о каком-то кеше? Это относится к реализации. Конечно если вы пишете нечто, которым планируете пользоваться единолично, этот пункт к вам не относится

4) Аргумент 2NetFly по поводу межязыковой переносимости

 

[SiMM]

Вот собственно и пришли к тому, что нужно знать, зачем этот конфиг нужен - говорить же безапелляционно, что xml/ini/php лучше (особенно аргументируя это модностью), не рассматривая среды применения - нет никакого смысла. Если речь идёт о настройке скрипта (логин/пароль к базе и другая мелочёвка) - то вполне можно использовать php.

 

[Фанат]

Макс
Вопрос не в том, зачем писать такие фреймворки. А в том - сколько их в реальности?
Спасибо за пример случая, когда без кэширования конфигов (которые, на самом деле, есть часьи скриптов). И что дальше?
Если Автомобиль БелАЗ имеет грузоподьемность сто тонн то моя легковушка обязана иметь столько же?
Может быть, воздержаться от маргинальных примеров?

 

[Макс]

Дело даже не в количестве а в их известности.
Prado и упоминаемый выше Propel - это очень известные разработки и когда ПХП5 появится на хостингах, они будут использоваться немалым количеством программеров.

Если Автомобиль БелАЗ имеет грузоподьемность сто тонн то моя легковушка обязана иметь столько же?

нет, но будет круто, если этот БелАЗ будет развивать такую же скорость как и твоя легковушка

 

[Фанат]

Хорошо, убедил.
Когда каждая функция имеет свой конфиг - да, кэширование просто необходимо, дозарезу.

Отстал я совсем.
Пароль к базе пишу в общем конфиге.
А надо-то, оказывается, писать в конфиге к mysql_connect.

-~{}~ 03.12.04 15:20:

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