On 9/30/10 7:11 PM, Jeremy Mikola wrote:
I didn't consider the ambiguity between attributes and child nodes.
That's a good point.
If there is ever to be a mechanism to validate the processed $config
array that Symfony passes to each extension loader (I wasn't too
concerned about YAML specifically), it would certainly need to be
configured in some unique manner and not the XSD file used for XML configs.
That's something that we should be able to do. After loading a
configuration, it's converted to an array (that's true for all loaders
-- XML, YAML, or PHP). So, just before calling the *Load() method, we
can probably "validate" the array. I see two possibilities here:
* Validation is done by the extension directly (via a *Validation()
method); that's easy to do but then each extension needs to implement
its own validation mechanism
* We "invent" a way to validate an array of configuration parameters.
Or, is it something that already exist?
Fabien
On Thu, Sep 30, 2010 at 12:43 PM, Bulat Shakirzyanov
<[email protected] <mailto:[email protected]>> wrote:
I don't like the idea of using XSD for YAML validation.
* First of all, it feels like magic and magic will bite you.
* Secondly there is a fundamental difference between xml and
yaml/json formats. That is xml nodes can have values and
properties, whereas yaml/json nodes are limited to properties
only. This makes xml much more flexible and expressive
configuration language than anything else. And also breaks any
possibility of validation of property-only configurations,
since it cannot always be mapped directly to xml.
* Third reason is if we decide to go that route and use a common
validation, we limit ourselves to the capabilities of the most
limited configuration language, that is there (yaml), making
the xml confutations much more verbose and hard to read.
<service id="service_id" class="ServiceClass" />
now would become
<service>
<id>service_id</id>
<class>ServiceClass</class>
</service>
and even worse with xml routing files
* Last reason is the simple premise - use right tool for the job
and XSD is not right tool for validation of YAML
* in fact, there is no right tool, as YAML by definition
On Thu, Sep 30, 2010 at 12:07 PM, Jeremy Mikola <[email protected]
<mailto:[email protected]>> wrote:
On Sep 29, 1:33 pm, Lukas Kahwe Smith <[email protected]
<mailto:[email protected]>> wrote:
> On 29.09.2010, at 10:27, Francois Zaninotto wrote:
>
> then again it could just mean that someone could try to
implement applying XSD validation directly on yaml aka
interpreting the XSD rules and then checking the yaml if it
passes. we might just support a subset of XSD for the time being
which might cover most use cases already .. not sure .. just
thinking allowed here.
A co-worker of mine just suggested this while I was sharing an XSD a
made for a bundle I'm working on. I think that's definitely
do-able,
and would make for a great Symfony2 console command. It wouldn't
necessarily have to map back to a specific line in the YML,
rather the
XSD could validate the entire configuration once it is loaded by
various drivers (XML, YML, PHP, annotations) and then report errors
such as "validation: enabled expected boolean, string given".
A side-benefit of this would be only requiring bundle developers to
make a single file to serve multiple purposes, vs. additional
schema/
validation files in whatever format to validate YML, PHP, and other
formats. Thought perhaps this is a mis-use of XSD?
--
If you want to report a vulnerability issue on symfony, please
send it to security at symfony-project.com
<http://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] <mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:symfony-devs%[email protected]>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
If you want to report a vulnerability issue on symfony, please send
it to security at symfony-project.com <http://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]
<mailto:[email protected]>
To unsubscribe from this group, send email to
[email protected]
<mailto:symfony-devs%[email protected]>
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
jeremy mikola
--
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
--
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
