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 Zeppieri > Sent: Saturday, November 18, 2006 6:32 AM > To: rt-users@lists.bestpractical.com > Subject: [rt-users] (Mason related question) <%filter> > section in the toplevel autohandler does not work as expected. > > > Hi! > > This is probably a Mason question, not an RT question, but since I'm > completely new to both Mason and RT, and this problem > happened to me for > the first time just tonight, right after my very first RT installation > and subsequent Mason experiments, you can probably easily > reproduce the > problem or point me to the right direction (that is, let me abuse of > your competence about Mason, and your kindness). > > I placed a <%filter> block in the topmost RT autohandler component > (/opt/rt3/share/html/autohandler in my layout) and I expected > to be able > to filter any HTML code generated by RT, instead the > <%filter> block got almost completely bypassed, that is, upon the > (unique) filter activation $_ contained only the few last > HTML lines of > the generated page (thus even $_ = '' inside the <%filter> section did > basically not alter the page). > > 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 > 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. > 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 directory is empty. > > I've also searched through the Mason bug-reports, and this one, 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? > > (I'm just curious about the way Mason works, and I have no > intention to > customize RT this 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 > > BTW, RT is great! :-) > > Thank you, > Emanuele. > > > _______________________________________________ > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users > > Community help: http://wiki.bestpractical.com > Commercial support: [EMAIL PROTECTED] > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
