The good thing about what Fabien is suggesting is that we would be able to validate any config format independently. So rather than making XML default (which on a side note, I am personally against) because it can be validated against an XSD, we can validate any format anyway.
XML is by far the most verbose of the config formats and I think that it's verbosity makes it the most complex and the hardest for a junior to learn. YAML was very easy to pick up when I first switched to Symfony and while I'm in favour of supporting other formats, I really don't see a need to replace it as the default. Kind regards, Keri Henare --------------------------------------------------- Chief Technical Officer Pixel Fusion [e] [email protected] [w] pixelfusion.co.nz [m] (+64) 021 874 552 [p] (+64) 09 550 3084 Zend Certified Engineer - http://www.zend.com/en/yellow-pages#show-ClientCandidateID=ZEND013450 PLEASE NOTE: I check my email 3 times per day and will respond at these intervals. For anything urgent please ring me. --------------------------------------------------- On 1/10/2010, at 6:29 AM, Yuen-Chi Lian wrote: > 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] > <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 > > > -- > 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
