On 10-10-24 01:51 PM, Jordi Boggiano wrote:
On Sun, Oct 24, 2010 at 5:03 PM, weaverryan<[email protected]> wrote:
1) Shouldn't each DI extension have a unique namespace/alias (with
respect to other extensions)?
Nothing to add, I've used mostly yaml so I didn't ran into issues. But
I guess you're right.
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).
I think XML namespaces and xsd and lala are overly complicated, you
can really end up with very hard to debug situations if you're not
careful or don't know too much about XML, where you just forgot a
namespace prefix, or a declaration in the main xml node. I'd really
like to move the "standard" back to Yaml.
+? for default to Yaml. XML is way, way, way too harsh. Using Yaml
flattens the learning curve.
The FrameworkBundle DI extension uses "app", which I find
confusing since we use "app" and "Application" to refer to end-user
code.
I'd be +1 for an app -> framework rename. Note however that now the
FrameworkBundle also provides a security ext/alias.
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
I'll work on a patch for Sf core that implements that and hopefully
some tests. Getting some feedback in that thread would be nice though
:)
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.
Another reason to go for YML by default - well actually you'd need to
drop XML altogether I guess if you want to remove those xml-specific
methods, or is it just needed to load the bundle's config?
As I've said previously, I'd be happy to contribute a Yaml validator
based on Kwalify (http://www.kuwata-lab.com/kwalify/) if there is
interest and it can lead to yaml being default.
Cheers
--
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
