-- darkangel <[email protected]> wrote
(on Thursday, 25 February 2010, 07:06 AM -0800):
> weierophinney wrote:
> > This is an interesting idea, but I have no plans to implement it in the
> > 1.x branch. In 2.0, you will have the option of defining your own
> > decorator chains as classes -- which means that you should be able to
> > specify the name of a decorator chain class when defining an element,
> > and it will use that. This allows you to define the chain once, and use
> > it simply many times.
> >
> Thanks for your reply, Matthew.
>
> Isn't that basically the same as doing:
>
> class MyForm extends Zend_Form
> {
> public function init()
> {
> $decorators = array('ViewHelper', 'Label', 'Whatever');
>
> $element1 = new Zend_Form_Element_Text();
> $element1->setDecorators($decorators);
It's actually quite a bit different.
With an array of decorators, you can't re-use the same set of decorators
by name, only by that array, which means you can't use configuration.
Try this:
$element1->setDecoratorChain('My_Default_Decorators');
This can then also be simplified to:
$element1 = $this->createElement('element1', array(
'decoratorChain' => 'My_Default_Decorators',
));
This latter allows for configuration.
> $element2 = new Zend_Form_Element_Text();
> $element2->setDecorators($decorators);
> }
> }
>
> ? Still means you have no control of the default decorators (i.e. you have
> to specify them each time you create an element).
Yes, this latter is true. For this, however, there are a few
considerations:
* Should the factory method for creating an element inject default
decorators? The problem with this approach is that not all elements
work with all decorators, which can lead to bad or incoherent markup.
* Should default decorators be a static property on individual element
classes? This is the most flexible, but requires some setup (which
can be the responsibility of a bootstrap resource or a class -- see
Zend_Dojo::enableForm() as an example), and also has consequences
when multiple forms are in play (not all forms may require the same
defaults).
When it comes down to it, the default decorators are simply a decorator
chain like any other. The current solution exists so that you can
customize per-instance -- and the way to do that is to pass in
decorators at or following construction. Personally, I prefer this
approach as I'm then being explicit in my code about what I'm choosing.
Having class-based decorator chains will make the situation much less
verbose and configurable in the end, as well as more performant; I think
this will address the bulk of concerns about customizing decorators.
--
Matthew Weier O'Phinney
Project Lead | [email protected]
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
