Должен ли я использовать YAML для файлов конфигурации в приложении PHP?

Question

В настоящее время я пишу свою собственную PHP Framework (для удовольствия, а не для критически важных вещей), и я пытаюсь добавить функциональность, где пользователь может настроить, какие базы данных должна использовать инфраструктура (первичная база данных, а затем, возможно, один или два запасных варианта (например, sqlite), где находятся определенные файлы и т. д. Должен ли я использовать YAML для этого? Есть ли лучший подход или стандартная практика?

Мои мысли

1. YAML удобен в использовании (нетехнически) с точки зрения читаемости
2. Чтобы моя платформа не требовала нестандартных библиотек PHP, мне нужно было использовать что-то вроде Symfony YAML для анализа файла.
3. Разве Symfony не уходит от YAML?
4. Я мог бы использовать PHP-файл, полный переменных, но это сделало бы настройку инфраструктуры менее прозрачной для пользователя.

Обновление

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

Общие вопросы, которые у меня есть

1. Каковы преимущества YAML перед другими подходами, такими как XML или даже настройка файла INI?
2. Какое эмпирическое правило относительно того, когда использовать YAML над этими другими подходами или наоборот?

Answer 1

НЕТ

Личный опыт.YAML кажется замечательной идеей, и мне очень понравилась ее простота.Затем я начал тратить на это время: та же самая идея о том, чтобы читать на одном языке и писать на другом, была очень соблазнительной, но ... короче говоря, это оказалось простой иллюзией , не подтвержденный фактами.

Каждая реализация YAML слишком сильно отличается от других .

• Массивы, автоматически сериализуемые одним, иногда не могут быть прочитаныдругим.

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

  Ссылки являются мощными, но:

  • Они весьма ограничены для некоторых хардкорных приложений.
  • Они представляют собой перерасход для большинства бюджетных проектов на базе YAML.

  
  Итак, часто они игнорируются, и ошибаются при , большинством анализаторов.

Подводя итог,Стандарт не очень хорошо установлен.

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

Там не различие уровней совместимости , как в DOM (DOM level 1, DOM level 2и т. д.), поэтому каждый разработчик синтаксического анализатора реализует то, что он чувствует, в той степени, в которой он может выдержать, затем отбрасывает это, и трудно различить, что работает, а что нет .

ИспользованиеАльтернативы

• JSON , если вы цените межязыковой язык обмена данными и небольшая избыточность аспекты как главный приоритет

• INI , если вы оцениваете pэргономичность и обратная совместимость ( на PHP , так как parse_ini_file() быстрый, и с тех пор ... всегда) и удобочитаемость / возможность редактирования людьми вместо

Answer 2

Мое личное предпочтение - для файла конфигурации на основе PHP.

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

$config = array(
  'database' => array(
      'default' => array(
         'name' => 'dbname',
         'host' => 'localhost',
         'user' => 'username',
         'pass' => 'password'
      )
   )
);

, тогда вы можете ссылаться на настройки конфигурации, такие как

$host = $config['database']['default']['host'];

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

Answer 3

Я копаю немного больше для формата файла конфигурации и нашел интересные факты для формата YAML.

В основном у него мало недостатков

1) Это включает в себя установку и настройку дополнительной библиотеки PHP, так как модуль YAML не поставляется по умолчанию или должен быть отделен от фреймворка Symphony и использовать его.

2) Производительность чтения и записи худшая среди всех технологий конфигурации, если сравнивать с INI, XML, JSON. Чтение намного больше времени по сравнению с INI-файлом http://konrness.com/php5/zend_config-benchmark-json-array-ini-xml-yaml/

3) Читаемость не очень хорошая, сравните с форматами INI и XML. Когда он стал большим, тогда трудно читать и управлять гуманными глазами.

4) Немного громоздко сравнивать с INI и JSON.

Так что лучше использовать формат INI, а не YAML.

Answer 4

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

Разве Symfony не уходит от YAML?

Нет, Symony2 почти полностью настроен на YAML.

Answer 5

использовать JSON хорошая идея
для загрузки конфигурационного файла

"username" : "root" //in json file 

 $json = file_get_contents('path/to/file');
 $data = json_decode($json);
 $data->username; //print root

для записи конфигурационного файла

$data['username'] = 'root'; 

if (file_put_contents('path/to/file', json_encode($dat))) { echo "<h4 class='alert alert-success'>config updated</h4>"; }

Последнее, что нужно, если вы используете веб-root: .htaccess

<IfModule authz_core_module>
Require all denied
</IfModule>
<IfModule !authz_core_module>
Deny from all
</IfModule>

Answer 6

Обычно я делаю XML-файл и создаю независимый интерфейс для изменения настроек в XML-файле.