AW: [rt-users] RT 3.4.3 / Can't locate object method "GetDisplayedNodes" via package "Tree::Simple" at /opt/rt3/share/html/Search/Build.html line 270.

[Todd Chapman]

On Mon, Sep 12, 2005 at 05:44:32PM -0400, David Glasser wrote:
> On Sep 12, 2005, at 3:42 PM, Todd Chapman wrote:
> 
> >Well, I am running Asset Tracker. Its search builder is based
> >on the RT code, before the major refactoring. Perhaps there is
> >a global variable that AT is stepping on?
> 
> Having taken a glance at the AT source, I think I understand the  
> problem.
> 
> This bug does not exist in vanilla RT -- I don't believe you can make  
> this happen without adding your own code.  However, RT's html/Search/ 
> Build.html is written in such a way that it makes such a bug easy to  
> accidentally make.
> 
> Specifically, I believe that whenever you do "sub foo {" in a Mason <% 
> INIT> or <%PERL> block, the sub is actually defined in the package  
> HTML::Mason::Commands.  Specifically, this means that if two  
> components define subs with the same name, they will clash.
> 
> I believe what we were seeing here was a clash between ParseQuery in  
> RT's html/Search/Build.html and AT's AssetTracker/Search/Build.html  
> --- these are two separate pages, but they both define ParseQuery,  
> and so in some cases RT's page ended up calling AT's function.
> 
> It seems that defining subs in components should be avoided.  (Of  
> course it's usually better to put subs in lib/ anyway.)  I will check  
> in a fix that changes the subs in html/Search/Build.html to be  
> closures assigned to a lexical variables; essentially, I am changing  
> "sub ParseQuery {" to "my $ParseQuery = sub {".
> 
> (It looks like Elements/RT__Ticket/ColumnMap and (in 3.5) Elements/ 
> MyRT could use a similar fix.)
> 
> --dave
>   Code Monkey, Best Practical Solutions
> -- 
> David Glasser | glasser at bestpractical.com
> 
Though with your fix it won't be necessary, I'll do similar in AT
and release a new version ASAP.

-Todd