[Rt-devel] [patch] RT::Interface::Web _Overlay/_Vendor/_Local not being included

[Kevin Falcone]

On Wed, May 18, 2011 at 05:39:19PM -0700, Ivan Kohler wrote:
> Sorry to be a pain.  Any idea here now that the dust has settled from 
> 4.0.0?  I'd really like to see this fixed and Web_Vendor/_Local files 
> working again.

Fixes have been on trunk since yesterday and in branches for a while.
You can follow rt on github here
https://github.com/bestpractical/rt/

-kevin

> I would be happy to contribute a patch if someone from the RT 
> team could let me know your preference wrt the options for fixing this I 
> outlined below.
> 
> -- 
> Ivan Kohler, President and Head Geek, Freeside Internet Services, Inc.
> Open-source billing, ticketing and provisioning - http://www.freeside.biz/
> 
> 
> On Tue, Apr 26, 2011 at 06:48:23PM -0700, Ivan Kohler wrote:
> > On Tue, Apr 26, 2011 at 11:04:52PM +0800, Jesse Vincent wrote:
> > > 
> > > On Mon 25.Apr'11 at 17:05:22 -0700, Ivan Kohler wrote:
> > > > On Thu, Apr 21, 2011 at 06:18:40AM +0400, Ruslan Zakirov wrote:
> > > > > Hello,
> > > > > 
> > > > > This is still doesn't return old behaviour. Which was with side effects.
> > > > > 
> > > > > Old code was loading .../Web_Local.pm, but code was compiled in
> > > > > HTML::Mason::Commands space unless explicit package is defined in
> > > > > _Local.pm file.
> > > > 
> > > > 
> > > > Okay, how about this instead of the previous patch:
> > > 
> > > I believe killing string eval was an explicit goal of the rewrite.
> > 
> > 
> > So far, I haven't thought of a way to change the current namespace 
> > without string eval.  "package" doesn't take a scalar.  Any suggestions?  
> > Perhaps it can't be done?
> > 
> > Assuming that's the case, how would you like to reconcile the goal of 
> > killing string eval with Ruslan's request to evaluate the files in the 
> > HTML::Mason::Commands namespace?
> > 
> > 
> > 1. Give up on eliminating string eval? (the current patch, probably 
> > isolated to a Web.pm-only version of _ImportOverlays)
> > 
> > 2. Give up on the idea of changing into the caller's current package?
> > (HTML::Mason::Commands).
> > 
> > 3. Some sort of namespace chicanery to evaluate everything in a 
> > temporary package and then alias it into the desired package?  (without 
> > string eval)
> > 
> > 
> > #2 is my preference - I don't think preserving the "Web_*.pm overlays 
> > are in the HTML::Mason::Commands namespace" behavior is particularly 
> > important.
> > 
> > I'd be happy to contribute a patch implementing #1 or #2.
> > 
> > #3 may be more than I can bite off Real Soon, but I guess I could give
> > it a try if that's the only way you'll even consider fixing the original 
> > bug that the files aren't pulled in at all...  :)
> > 
> > 
> > -- 
> > Ivan Kohler, President and Head Geek, Freeside Internet Services, Inc.          
> > Open-source billing, ticketing and provisioning - http://www.freeside.biz/
> > 
> > _______________________________________________
> > List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
> 
> _______________________________________________
> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-devel/attachments/20110519/d784ff38/attachment.pgp>