Good morning,
I spent the weekend looking into the problem I posted last week about
$m->clear_buffer not working within component-with-content calls.
I've got another test-case here that makes this even more apparent,
and perhaps suggests (to someone that knows the code?) what might be
happening.
First, here's the test component in its entirety:
------------------------------
Output 1
<&| .Foo &>
Output 2
<& .Bar &>
Output 3
</&>
Output 4
<%def .Foo>
Output 5
<% $m->content %>
Output 6
</%def>
<%def .Bar>
Output 7
% $m->clear_buffer;
Output 8
</%def>
------------------------------
With the $m->clear_buffer commented out, the expected output results:
Output 1
Output 5
Output 2
Output 7
Output 8
Output 3
Output 6
Output 4
With $m->clear_buffer in place, I would expect all output before
"Output 7" to be cleared, and for things to start from Output 8 and
continue as above. This doesn't happen ... here's the output (in
Mason 1.32):
Output 1
Output 5
Output 8
Output 3
Output 6
Output 4
This output seems to imply that the $m->clear_buffer only partially
propagates up, only so far as the component-with-content buffer
(nothing before that clears out).
Also (interestingly it seems) it looks like $m->content is called
"early" within .Foo, since Output 5 still makes it out, even though
it seems to be "after" the $m->content which triggers the $m-
>clear_buffer.
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.
For note, running Mason 1.28 produces the "expected" results:
Output 8
Output 3
Output 6
Output 4
Everything just before Output 7, the last output before the $m-
>clear_buffer, is nuked as expected.
Anyone shed any light on this behaviour? Is this correct behaviour in
Mason 1.32? If so, I'd be happy to update the Wiki docs to better
represent the implications of $m->clear_buffer.
And notably, the issue which prompted my initial investigation, is
that $m->redirect (or any other call I imagine that requires $m-
>clear_buffer to actually clear the buffer) is not functional within
the context of a wrapping component-with-content.
Final question: any thoughts on where to look to fix the problem? I'd
be happy to help out. Right now my options seem to be:
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).
Any/all feedback greatly appreciated,
-Michael
_______________________________________________________
Michael Burns
Cosbit Technologies
403-701-2672 / [EMAIL PROTECTED]
AIM: cmikeburns
MSN: cmikeburns
_______________________________________________________
Box 2173, Station M • Calgary, Alberta, Canada • T2P 2M4
http://cosbit.com
-------------------------------------------------------
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&kid3432&bid#0486&dat1642
_______________________________________________
Mason-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mason-users
