Issue Type: Improvement Created: 2010-03-18T03:19:50.000+0000 Last Updated: 2012-11-20T21:38:13.000+0000 Status: Open Fix version(s): Reporter: Marc Thomas (existenz) Assignee: None Tags: - Zend_Form
Related issues: Attachments:
I have try some tests and have notice behaviours which are more or less strange.
I introduce them through two points :
(I have choice to defined this issue as 'improvement' but that can be more or less a 'bug', especially for second point)
1/ 'disableLoadDefaultDecorators' behaviour : When using 'disableLoadDefaultDecorators' set to "false", we expect (at first sight) that default decorators will be loaded, whatever user "decorators" options exist or not.
But it is not the case : if user has defined at less one decorator option then default decorators will not be loaded, as if 'disableLoadDefaultDecorators' was set to "true".
However, we could want that user "decorators" are added to default ones. I think either the method could have a different name, either it could be have a behaviour going in this sense.
I could imagine this behaviour is deliberated, so that the user does not lost himself with decorators order if both (default and user ones) are loaded, but I think the user should have the choice.
2/ decorator names resolution, associated to 'disableLoadDefaultDecorators'
Case 1 : When using 'disableLoadDefaultDecorators' set to "false", all user decorators (defined in "decorators" option on an element) are resolved : their name become object (via a calling to the PluginLoader).
Case 2 : However, when using 'disableLoadDefaultDecorators' set to "true", no resolution happens.
I think this point is very strange, because we do not expect from 'disableLoadDefaultDecorators' a such behaviour. It has even some consequences, in the case where addElements() receive form elements object instead string one and user "decorators" option exists : - With case 2, elements can benefit from form paths (ie. $form->addElementPrefixPath() ) - And with case 1 it is not the case, because decorator names have been resolved during element instanciation (before beeing added to the form, so having not knowledge of form "prefixElementPaths" values)
In one case they are resolved during instanciation, in other case they are later. I think they should be resolved later in all cases if that doest not matter, allowing user decorators to be set with benefiting from elementPrefixPath of the form instead of having to using "prefixPath" for each elements as option.
For the moment, even if we want default decorators, the only solution is to disableLoadDefaultDecorators() and adding them in option.
What do you think about ?
No comments to display
Have you found an issue?
See the Overview section for more details.