On Mon, 23 Jan 2006, Michael Burns wrote:
In any case, this certainly doesn't seem to mesh with the most current
documentation I could find about changes to $m->clear_buffer. From the
changelog for 1.29_01, 1.29_02, and 1.30, the statement is:
1.29_01 January 25, 2005
[ INCOMPATIBLE CHANGES ]
- ** The behaviors of $m->flush_buffer and $m->clear_buffer have been
simplified. $m->flush_buffer only acts on the top-level output buffer;
$m->clear_buffer clears all output buffers. Task id #554.
This doesn't seem to represent what is happening ... at least for
component-with-content calls.
Yeah, I think we're definitely seeing a bug. Calling $m->clear_buffer is
supposed to unconditionally wipe all output generated up to that point,
_unless_ it's been flushed (in which case it's already gone from Mason).
1. Understand better how the output stack works to suggest a fix to the group
so I can run my web app under Mason 1.32 -- my preferred solution :-)
2. Keep running Mason 1.28
3. Remove/rework all component-with-content calls in my web app to ensure
nothing relies on a $m->clear_buffer call, and then use Mason 1.32 (probably
what I'll do if I can't do #1).
4. Send a patch to fix the bug.
5. Stay with 1.28 until Jon or I fix it and make a new release.
#4 would be great, but #5 is probably viable too ;)
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
