Matthew, What do you need to reproduce it? The controller, config, view, etc.?
TJ. On Wed, Jul 16, 2008 at 7:32 PM, Matthew Weier O'Phinney <[EMAIL PROTECTED]> wrote: > -- 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/ >
