Hey guys- I'd like to get some opinions regarding DI extensions. So far, I think this is the most daunting obstacle facing a new Symfony2 developer. Here are some thoughts and questions:
1) Shouldn't each DI extension have a unique namespace/alias (with respect to other extensions)? I believe the answer is yes. Currently, if two DI extensions specify the same namespace or alias, one will replace the other. Is this intentional so a developer can somehow "override" a DI extension or can we throw an exception when this happens? There are several well-known SF2 bundles that specify the symfony namespace (http://www.symfony-project.org/schema/dic/symfony). This breaks everything if xml configuration is used (the FrameworkExtension is overridden with a bundle extension), but the actual exception is quite unclear. We allow DI extensions to silently override each other (and this might only happen in XML and not YAML - see next point). 2) The dichotomy of having an "alias" AND a "namespace" is not ideal. This can cause a disconnect between the configurations - especially if two DI extensions unintentionally use unique aliases (so YAML works) but specify the same namespace (XML breaks - one DI extension overrides the other). We're seeing this in several OS bundles (see above). 3) I'm worried about the documentation of the configuration for each DI extension for three reasons. The overarching solution is that emphasis will need to be placed on good, deliberate documentation of the config both in the core and community bundles: a) There's no automatic connection between an alias/namespace and the bundle that provides it. We're all beginning to follow a convention here I think we should encourage it (i.e. doctrine => DoctrineBundle, doctrine_user => DoctrineUserBundle). Obviously, a bundle could specify more than one DI extension, but that's not the norm. The FrameworkBundle DI extension uses "app", which I find confusing since we use "app" and "Application" to refer to end-user code. b) So much logic of each DI extension is contained in the XXXXLoad() method. That's fine, but it's in a format that's inherently not "self- documenting". It's actually similar to symfony1 in that each factory.yml "param" key is used in a custom way inside the factory class itself. There's also a conversation started by Jordi related to consistency in how these methods are written: http://groups.google.com/group/symfony-devs/browse_thread/thread/b8cdd4c45eb4d60d/2d64037fc7ed374d c) Since all the OS & core bundles will (should) use XML configuration, the config is even less self-documenting. For its faults, that was the advantage of YAML in symfony1 - it's free of extraneous markup, making it fairly self-documenting. Again, the emphasis will need to be on true documentation in Sf2. 4) Creating a DI extension is hard. This process entails creating the class, specifying the 4 abstract methods (including two that are entirely for XML) and creating a schema for your XML. This is fine/ great for OS bundles, but it seems a bit daunting if a dev chooses to use application bundles with DI extensions. On that note, what IS the best practice for including DI config from an application bundle - should a DI extension be used or should we use an "import" of some sort from the root application's config file? Thanks! -- 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
