-- Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote (on Monday, 14 July 2008, 08:54 AM -0400): > -- 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.
I've written tests to cover this situation, and updated the code to ensure that plugin order is retained during lazy loading. Please test and confirm! -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
