Hi, The new implementation should be merge tomorrow. see http://trac.symfony-project.org/wiki/IRCLogs20110317
So now time to get back to the first message from Lukas. I won't be available next week to work on this but I have some idea about what should be done: (Those are just some rough ideas that probably need more thinking...) - Create a DocumentableInterface interface with a setter method doc(), - All builders (except NodeBuilder) should implement this interface - to document validation, normalization, ..., - NodeDefinition should also implement this interface - to document nodes. - Create a ConfigurationInterface interface, - This interface should have a getTreeBuilder() method, - Create a concrete base configuration class implementing the ConfigurationInterface and a getTree() method ($tree->buildTree()) - Make all the configuration classes extend this base class Then we should look at writing the command to generate the doc: - Look for Configuration.php files in the DependencyInjection folder of each bundles - Bundle::registerCommands is a good example, - Get the treeBuilder, - Generate the doc, We're done ! One of my idea was to dump the tree to an XML file and use XSLT to generate the docs & XSD. That is not the only way and may be not the best way but that is something I wanted to try... Cheers, Victor On Mar 13, 5:58 pm, Victor Berchet <[email protected]> wrote: > All the remaining configuration files from Symfony2 have been > converted now. > > I have not been able to validate the SecurityBundle configuration as > it would require a full setup that i do not have ready. > Could someone help me on this one ? > This means pulling my branch and issue any request in order to have > your security.yml parsed. > > Thanks, > Victor > > On Mar 13, 2:15 pm, Victor Berchet <[email protected]> wrote: > > > I have done some more changes to the config component and the current > > state is more or less where I wanted it to be. > > The code is in my cfg_refactor > > branch:https://github.com/vicb/symfony/compare/master...cfg_refactor > > > ** API breaks: > > > - The children of array nodes must be enclosed in "->children() ... > > ->end()" calls (there could be multiple children blocks for the same > > > node in order to improve readibility), > > - The 'builder' method (previously located in the NodeBuilder class) > > is now a 'append' method in the ArrayNodeDefinition. > > > Framework, Zend, Twig and Doctrine bundle configurations have been > > converted to the new format. > > You might want to look at those for migrations examples. > > > ** Benefits: > > > - You don't have access to a bunch a public properties any more (they > > are made protected on definition classes), > > - Most logic errors will be catch at runtime rather than silently > > ignored, i.e. : > > ...->scalarNode('cache_warmer') > > ->scalarNode('dummy') > > ->requiresAtLeastOneElement() > > ->end() > > ->end() > > - When using the autocomplete in your IDE, 'scalarNode' and > > 'requiresAtLeastOneElement' are not in the proposed choices. > > > ** Cons: > > > - At stated by stof, the configuration is a bit more verbose with the > > children() and end() calls. > > - ... ? Let me know > > > ** Going further: > > > I think we should decide if this should be merged into the master > > branch (after converting the remaining bundle configuration files & > > squashing the commits). > > > Once we have decided (not?) to merge this in the master branch then we > > can start working on the topics listed by Lukas. > > I believe that the proposed implementation is easily expandable to > > support those. > > > My vote: +1 for merging ;-) > > > On Mar 12, 4:35 pm, Johannes Schmitt <[email protected]> wrote: > > > > I think you shouldn't put too much effort into the builder classes as > > > these > > > will never be "clean" unless we abandon the fluid interface. The builder > > > classes' only responsibility is the construction of actual node objects, > > > and > > > these node objects contain the business logic that is then cleanly > > > separated > > > in several different node classes. You'll not be able to achieve the same > > > clean separation in the builder classes. > > > > Kind regards, > > > Johannes > > > > On Sat, Mar 12, 2011 at 4:24 PM, Victor Berchet > > > <[email protected]>wrote: > > > > > That's the only solution I found to work around PHP not supporting > > > > multiple inheritance: ArrayNodeDefinition should extend NodeBuilder > > > > but it already extends NodeDefinition... > > > > > On Mar 12, 3:04 pm, Christophe COEVOET <[email protected]> wrote: > > > > > Le 12/03/2011 14:49, Victor Berchet a crit : > > > > > > > Lukas: > > > > > > > Thanks for the details. > > > > > > > All: > > > > > > > I have just pushed a new commit to my branch: > > > > > >https://github.com/vicb/symfony/tree/cfg_refactor > > > > > > > That's just a proto for now (the code is dirty), waiting for some > > > > > > feedback. > > > > > > > This last commit breaks the configuration API, and only the > > > > > > Framework, > > > > > > Twig and Zend Bundles have been updated. > > > > > > > What about being able to dump the configuration to XML (this would > > > > > > be > > > > > > done in the NodeDefinition classes) and generate docs and XSD files > > > > > > using XSLT ? > > > > > > > Cheers, > > > > > > Victor > > > > > > I don't see the reason of adding a ->children() call around the > > > > > children. This extra level of builder seems weird to me. > > > > > It breaks the BC and makes the Configuration class more verbose. What > > > > > is > > > > > the purpose of this change ? > > > > > > -- > > > > > 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 -- 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
