Hey folks- There are at least three of us (Johanness, Jeremy and I) who've been working on refactoring how the DI extensions handle their config. Jeremy is refactoring the FrameworkExtension ( https://github.com/fabpot/symfony/pull/486) and I've got the DoctrineMongoDBExtension (https://github.com/fabpot/symfony/pull/510). Most of the extensions need a lot of work. Speaking for myself, the guiding philosophies are:
* A process of normalization (normalizing format differences), validation and merging (more on these later) should take place at the *beginning* of the config load process. The rest of the DI extension should be able to use options *without worrying* about any of the above topics. This is a big separation of concerns and makes the classes more readable. * All default option valuesshould be kept in a YAML file. This is the format that most end-users will use, so having it in its own file means that there is a real file to reference. This file can also contain comments and example configuration. For example: https://github.com/fabpot/symfony/pull/510/files#diff-4 <https://github.com/fabpot/symfony/pull/510/files#diff-4>In particular, the normalization and validation processes have proven *very* difficult, but predictable (summary of normalization issues: http://pastebin.com/4U4fiqdW). Most normalization is done custom and validation is a mixture of inferring info from the "defaults" array and custom overriding. The bottom-line problem is that we need more metadata about each individual option in order to normalize and validate all options without a mess of code. This is where Johanness' work comes in: https://github.com/fabpot/symfony/pull/554. This early prototype allows metadata to be specified on the DI extension options. The advantages are: * Each Extension can use this powerful class to specify the options metadata and then - in theory - be done. The Extension classes can get back to what they do best: use configuration to configure the DIC. This will also make those classes considerably more readable, which makes them more accessible to users who dive through the core code. * Validation could be very well-done. This validation is also format-agnostic. Since the validation would no longer rely on inferring from the defaults, the defaults themselves could be passed in as the first config array and would be validated. If something internal changed and the defaults were not updated, our own validation would actually catch this. I feel very good about our direction, but we've done so much work that I wanted to reach to everyone and get some feedback. Thanks! Ryan Weaver Lead Programmer - iostudio - Nashville, TN http://www.iostudio.com http://www.thatsquality.com Twitter: @weaverryan -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
