Le 09/05/2011 18:13, Alan Gabriel Bem a écrit :
Initialy, I have to say I preffer xml configuration over yaml, that is
why I'm writing this post. IMHO current implementation has few flaws I
want to share.
1. XSD Schema validation.
Despite that every XSD file is accesible locally, its filepath is
computed only when external XSD is definied in xsi:schemaLocation. It
means when no schemaLocation is definied for extension ns than no XSD
validation against that namespace occures.
Also this whole filepath computation is kind of magic (especially when
those files are right there.. just waiting), which Symfony tries to
avoid, right?
What if dev is using IDEs XML catalog, pointing at local files?
xsi:schemaLocation is somehow redundant.
Why not create more explicit Extension::getXsdFilePath()? Extensions
could even drop getNamespace() method and pull ns from XSD file.
The namespace is used to identify the configuration used by this
extension. This is mandatory to be able to use an XML config file.
The XSD is not mandatory. You just don't have the XSD validation if it
is not provided.
Requiring to have an XSD would mean that each bundle developer providing
a semantic configuration would have to provide an XSD file. But this
requires knowing the XSD syntax and writing it for XML users whereas
using validations rules in a Configuration class is more powerful: it
works also for YAML config, it validates the merged configuration (a
required key is not required in *all* files but in the merged config).
XSD validation is definetly not the better solution when merging some
configuration files.
2. Namespaces in ContainerBuilder.
It is possible now to get extension by its namespace, but... don't you
think namespaces don't belong there as they're only used by
XmlConfigLoader?
I think moving code responsible for extension lookup (by its
namespace) to loader, would add more clarity (also introducing few
loops, but since configuration files are compiled its not a big deal).
Why would it be done in the loader ? The loader is about loading a
config file, not about handling DI extensions.
Thus, the loader does not call the extension directly. it adds the
configuration values in the ContainerBuilder which will then call the
extensions with *all* configurations values. Moving it to an
XmlFileLoader would mean that you cannot import a YAML file from an XML
file or the opposite.
I wrote some code, which you can find
here:https://github.com/alanbem/symfony/tree/xml-config-improvements
P.S. Do you know that yaml configuration below is perfectly valid?
# config.yml
'http://symfony.com/schema/dic/symfony':
secret: %secret%
charset: UTF-8
csrf_protection:
enabled: true
router: { resource: "%kernel.root_dir%/config/routing.yml" }
validation: { enabled: true, annotations: true }
templating: { engines: ['twig'] } #assets_version:
SomeVersionScheme
session:
default_locale: %locale%
lifetime: 3600
auto_start: true
--
Christophe | Stof
--
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
