2008年8月30日星期六

Re: [fw-mvc] Firebug logger issues

Hey there,

This has already been resolved in http://framework.zend.com/issues/browse/ZF-3963, it should be fixed in RC3.

Later,


Matthew.

Matthew Weier O'Phinney wrote:
-- Adam Jensen <jazzslider@gmail.com> wrote (on Thursday, 14 August 2008, 08:49 AM -0500):   
Just confirmed it...manually calling Zend_Wildfire_Channel_HttpHeaders::getInstance()->flush() from within my layout script fixes the problem.  Is there a way the plugin could be refactored to address this issue?     
 This is useful information -- please add it in a comment to the issue report. It's very likely that the issue is indeed the order in which the plugins are being executed -- and there's actually a way to force the order that was added in 1.6.0.  Thanks for the continued sleuthing!    
On Thu, Aug 14, 2008 at 8:46 AM, Adam Jensen <jazzslider@gmail.com> wrote:     
On Wed, Aug 13, 2008 at 7:26 PM, Matthew Weier O'Phinney <matthew@zend.com> wrote:       
So, try and narrow down your reproduce case, to the smallest amount of code necessary, and then post it to see if others get the same results.         
I'm working on narrowing down a minimal reduce case, but it's been somewhat difficult given the number of components involved in all this...ordinarily I'd just write a simple test script and upload it, but I need the entire Zend_Controller_Front architecture for this one.  I have, however, found out at least one more relevant detail.  For whatever reason, I'm able to log to Firebug just fine in any context _except_ for layout scripts.  Are layout scripts rendered after the postDispatch() hook for the Channel plugin has already fired?  I think that would explain why any log messages fired off within that context never end up in the response headers.  I'll keep looking into it; meanwhile, please let me know if you've got any ideas for solving this.  Should I call the Channel plugin's flush() method myself from the end of my layout script?       
   

没有评论: