-- 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! -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
