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
