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?
没有评论:
发表评论