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

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

Мои мысли

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

Обновление

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

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

  • В чем преимущества YAML над другими подходами, такими как XML или даже установка файла INI?
  • Что такое хорошее правило о том, когда использовать YAML над этими другими подходами или наоборот?

Ответы

Ответ 1

НЕТ

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

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

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

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

    Ссылки мощные, но:

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


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

Подводя итог, стандарт не установлен правильно.

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

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

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

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

    /li >

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

Ответ 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'];

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

Ответ 3

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

Не отходит ли Symfony от YAML?

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

Ответ 4

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

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

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

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.

Ответ 5

Что я обычно делаю, это сделать файл XML и сделать необязательный интерфейс для изменения параметров в файле XML.

Ответ 6

использовать 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>"; }

Последнее, если вы в корневом веб-браузере используете этот .htaccess

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