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.

[David Glasser]

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