Matthew Weier O'Phinney schreef:
-- Bart McLeod <[EMAIL PROTECTED]> wrote
(on Monday, 14 July 2008, 02:07 PM +0200):
another addition:
The problem is in the new getDecorator function. If you call it, it
'lazyloads' the decorator, but puts it at the end of the stack. See this
output, where I var_dumped the decorators inside the lazy load function,
before and after getting the decorator 'td':
In the first array of 7 decorators, td is between errors and tr, where
it should be. In the second array, it comes after table, effectively
breaking the rendering chain.
Ah, okay -- I see what's happening, and it's a use case which didn't
have a test. I'll work on correcting it in the next 1-2 days.
As an explanationg, a little over a week ago, I refactored Zend_Form,
Zend_Form_DisplayGroup, and Zend_Form_Element to use lazy loading. This
was done for two reasons: a) to reduce overhead when plugins of a
certain type are never invoked, and b) to make it easier to set plugin
prefix paths at any given point in time, and have them affect previously
set plugins. (b) was partly to address Dojo and other JS library
integration.
Obviously, this has evidently created an issue of ordering plugins when
an individual plugin is fetched before others have been instantiated.
I'll write a test for this use case so that I can correct it in the next
couple of days so that it can get into the 1.6 release.
Thanks for the detailed sleuthing, Bart!
Always happy to add some real life testing! To make things worse:
something similar happens with addDecorator() if you add an arbitrary
decoractor to an already existing stack at a randomly chosen point in
time, somewhere between adding losts of other stuff and rendering the form.
Bart
