Search code examples
phpyaml

Should I use YAML for Config Files in a PHP Application?

I'm currently writing my own PHP Framework (for kicks, not for mission critical stuff) and I'm trying to add in functionality where the user can set up what databases the framework should use (a primary db and then maybe one or two fallbacks - like sqlite), where certain files are located, etc. Should I use YAML for this? Is there a better approach or a standard practice?

My Thoughts

  1. YAML is user (non-technical) friendly in terms of readability
  2. In order to keep my Framework from requiring non-standard PHP libraries, I'd have to use something like Symfony YAML in order to parse the file.
  3. Isn't Symfony moving away from YAML?
  4. I could use a PHP file full of variables but that would make setup of the framework less transparent to the user.

Update

I'm cleaning this question up to make it more constructive and to incorporate some of the answers I've gotten.

Overall Questions I Have

  1. What are the advantages of YAML over other approaches like XML or even an INI file setup?
  2. What is a good rule of thumb regarding when to use YAML over those other approaches or vice versa?
Solution

  • NO

    Personal experience. YAML seems a wonderful idea and I loved it and its simplicity. Then I started investing time on it: the very same concept of being able to read it in a language and write in another was very enticing, but... cutting it short, it turned up to be a mere illusion, unsubstantiated by facts.

    Every implementation of YAML differs too much from the other ones.

    • Arrays, automatically serialized by one, cannot sometimes be read by another.

    • Cross references are supported, but their implementation is really sketchy.

      References are powerful, but:

      • They are quite limited for some hardcore application.
      • They represent an overkill to most low-end YAML-based projects.


      So, frequently, they are ignored, and errored upon, by most parsers.

    Summing it up, the standard isn't well set.

    There are core concepts that are nice and simple, but the actual standard document is full of details about features that most people don't want to use and are difficult and expensive to implement.

    There isn't a distinction of levels of compatibility, like there is in DOM (DOM level 1, DOM level 2, etc) so every parser implementor implements what they feel like to, to the extent they can bear, then they drop it and it's hard to discern what works and what doesn't.

    Use Alternatives

    • JSON if you value the cross language data exchange language and little redundancy aspects as the top priority

    • INI if you value performance and backward compatibility (on PHP, as parse_ini_file() is fast, and there since... always) and readability/editability by humans, instead.