-- Codiac <[EMAIL PROTECTED]> wrote (on Wednesday, 16 July 2008, 10:16 AM -0700): > I've updated to the latest svn version, but nothing changed. The problem > still exists. I'll try and take a deep dive into the component and see if I > can spot the issue.
If you could just give me an example for reproducing the issue, I'll make the diagnosis and fix... And I'm going to need that reproduce case sooner or later. :) > Matthew Weier O'Phinney-3 wrote: > > > > -- Codiac <[EMAIL PROTECTED]> wrote > > (on Tuesday, 15 July 2008, 11:45 PM -0700): > >> Not entirely related, but i posted a bug at the issue tracker, ZF-3652, > >> which also seems to have been introduced after the updates in Zend_Form. > > > > Can you test from current trunk and let me know if this is still an > > issue? I committed some changes to fix the issue Bart reported > > yesterday, and those changes may have corrected this. > > > > > >> Matthew Weier O'Phinney-3 wrote: > >> > > >> > -- 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/ > > > > > > -- > View this message in context: > http://www.nabble.com/in-latest-standard-trunk%3A-decorators-seem-to-have-escaped-from-their-original-logic.-tp18441904p18492334.html > Sent from the Zend Framework mailing list archive at Nabble.com. > -- Matthew Weier O'Phinney Software Architect | [EMAIL PROTECTED] Zend Framework | http://framework.zend.com/
