I don't see the point to invent a way when XSD can do a fairly good job already (sadly just on XML). Must YAML and PHP be validated?
I just feel sorry if you can't get the simplest config - YAML - working. If you are using PHP to configure SF2 wrongly, you are probably writing code wrongly too and no one can help you to validate the latter. Yuen-Chi Lian | www.yclian.com "I do not seek; I find." - Pablo Picasso On Fri, Oct 1, 2010 at 1:21 AM, Fabien Potencier < [email protected]> wrote: > 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]<symfony-devs%[email protected]> >> >> <mailto:symfony-devs%[email protected]<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]<symfony-devs%[email protected]> >> >> <mailto:symfony-devs%[email protected]<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]<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 > > 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]<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 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
