Hi Dave,
On 23-Jan-06, at 10:16 AM, Dave Rolsky wrote:
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 ;)
#4 would work for me too ... can you suggest any development docs/
notes that I should look at? and/or, should future posts about this
move to another list (the developer's list or something)?
I've done some (basic) tracing and debugging output, and it seems
that within a component-with-content, additional components are
called without reference to the stacks above them, like they're being
called in an eval {} or with a clone of the parent $m or some other
such sandbox.
This is my first time looking through the Mason source so I'm still
not really sure what's going on :-) so I could be totally off-base.
It's interesting: when I do a Data::Dumper of the @{$m->{stack}}
array before the component-with-content, I see all the stacks to that
point, and I can see them being cleared out if I do a $m-
>clear_buffer and then dump them again.
However, doing a similar thing within a component called from within
a component-with-content call, only the most parent stack seems to
exist at all within the @{$m->{stack}} array, which is likely why
stuff isn't being cleared out ... the $m->clear_buffer does indeed
clear out all the stacks present at that point, but it doesn't reach
up far enough to clear out the stacks within the parent $m (seem to
be two different $m structures outside vs. inside the component-with-
content, at least so far as $m->{stack} is concerned).
Anyhoo, not sure if any of that is gibberish or not :-) I'll keep
poking around, any insight/pointers greatly appreciated. Thanks for
your response (and all your work on Mason etc.!!).
-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
