Upon further investigations, this unfortunately seems to be a Mason bug (or at least a documental hiatus) since I switched back to Mason 1.32 (just to test) and everything worked as expected: the filter section in the topmost autohandler received *all* the generated output (despite the presence of the various $m->flush_buffer in the other lower level components).
So, if not a bug, this is definitely a change in the way Mason autohandler works in conjunction with flush_buffer (a change introduced somewhere between versions 1.32 and 1.35), which is probably unintended (or at least undocumented). Can you please check this? Thank you, Emanuele. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Emanuele > Sent: Saturday, November 18, 2006 8:15 PM > To: mason-users@lists.sourceforge.net > Subject: [Mason] <%filter> in topmost autohandler bypassed in RT. > > > Hi! > > I'm completely new to Mason, and this problem happened just few hours > ago, right after my very first (though successful) Request Tracker > installation and my very first contact with Mason. > > (Running RT under mod_perl) I placed a <%filter> block inside the > topmost RT autohandler component > (/opt/rt3/share/html/autohandler in my > RT layout) thinking that this way I could filter any HTML > code generated > by RT, instead the <%filter> block got mostly bypassed, that is, the > filter block was entered *only* once and $_ contained only > the few last > HTML lines of the generated page (thus even $_ = '' inside > the <%filter> > section did basically not alter the page). > I expected instead that $_ contained the whole HTML page > generated by RT > (though possibly in several chunks). > > After a lot of digging in the Mason docs, I've tried removing some of > the various $m->flush_buffer scattered over the others RT's > Mason (lower > level) components, and this seemed to alleviate (if not solve) the > problem, in the sense that this way I could get much more HTML code in > $_ inside the filter placed in the topomost autohandler. > In other words it seems that $m->flush_buffer bypasses the <%filter> > block in a higher level component, which is different from what the > Mason docs state, if I understood them. > > Also consider that my local RT directory is empty, so it > can't interfere > in any way. > > I've also searched through the Mason bug-reports, and this > behavior, in > a sense, seems to be the opposite of an old Mason bug (now > fixed), which > caused $m->flush_buffer to be a no-op in presence of a <%filter> > block... > > Could you please check this problem, or tell me if I'm making some > stupid mistake or missing something? > > (BTW, I'm just interested about the way Mason works, and I have no > intention to customize RT this way, which I understand is not > the proper > way). > > My setup is: > > RT 3.6.2 RC1 (fresh installation, no customizations) > HTML::Mason 1.35 > perl 5.8.8 > Apache 2.2.3 > mod_perl 2.0.2 > Mac OS X 10.4.8 > > Thank you, > Emanuele. > > > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the > chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge &CID=DEVDEV _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mason-users mailing list Mason-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
