Plugins and _Vendor files

RT Developers
1

Unless I’m mistaken, no RT class will load more than one Vendor
overlay, so if I have two plugins installed, and each provide a Vendor
file, only one will get loaded.

Am I correct in surmising that the overlay mechanism was never really
meant to be used by plugins in this way? It seems most plugins only
need to make a couple of changes to RT classes and just do it right in
the main plugin .pm. Are there any other recommended methods?

For Asset Tracker, which has several _Vendor files, I’m thinking of
perhaps renaming them *_ATOverlay.pm and then requiring those from
AssetTracker.pm.

Thanks,
Bradley Bell
Classroom Support Services | University of Washington
035 Kane Hall | Box 353095 Seattle, WA 98195-3095
p 206.543.9900 | f 206.685.7892 | www.css.washington.edu

2

Unless I’m mistaken, no RT class will load more than one Vendor
overlay, so if I have two plugins installed, and each provide a Vendor
file, only one will get loaded.

Correct. The order is determined by the order of plugins listed in
@Plugins.

Am I correct in surmising that the overlay mechanism was never really
meant to be used by plugins in this way? It seems most plugins only
need to make a couple of changes to RT classes and just do it right in
the main plugin .pm. Are there any other recommended methods?

Correct. The standard way to do overlays these days is in your main
plugin .pm or other files that are loaded. Perl gives you all the rope
you need.

3

Unless I’m mistaken, no RT class will load more than one Vendor
overlay, so if I have two plugins installed, and each provide a Vendor
file, only one will get loaded.

Am I correct in surmising that the overlay mechanism was never really
meant to be used by plugins in this way?

Yes and no. In 3.6 nad older plugins were installed in local/ so you
couldn’t have two plugins with the same _Local.pm or _Vendor.pm file. We
were using such files in plugins, but quickly it proved to be wrong.

It seems most plugins only
need to make a couple of changes to RT classes and just do it right in
the main plugin .pm. Are there any other recommended methods?

see lib/RT/IR.pm in RTIR extension. We basicly wrap methods from
extensions’ primary file.

For Asset Tracker, which has several _Vendor files, I’m thinking of

perhaps renaming them *_ATOverlay.pm and then requiring those from
AssetTracker.pm.

Thanks,

Bradley Bell
Classroom Support Services | University of Washington
035 Kane Hall | Box 353095 Seattle, WA 98195-3095
p 206.543.9900 | f 206.685.7892 | www.css.washington.edu

–
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Best regards, Ruslan.

4

see lib/RT/IR.pm in RTIR extension. We basicly wrap methods from
extensions’ primary file.

You use here Hook::LexWrap and I saw some commit comments that
Hook::LexWrap makes some troubles:

Chris

5

Am 10.06.2013 20:36, schrieb Ruslan Zakirov:

see lib/RT/IR.pm in RTIR extension. We basicly wrap methods from
extensions’ primary file.

You use here Hook::LexWrap and I saw some commit comments that
Hook::LexWrap makes some troubles:
Remove Hook::LexWrap, and replace with a simpler glob manipulation · bestpractical/rt-extension-mergeusers@354edf0 · GitHub

In recent code we don’t use Hook::LexWrap as it’s in most case unnecesary.
Something close to the following should work just fine:

require RT::XXX;
{
my $orig = RT::XXX->can(“method”);
*RT::XXX::method = sub {
my $self = shift;
return $orig->($self, @_);
};
}

Chris

–
RT Training in Seattle, June 19-20: http://bestpractical.com/training

Best regards, Ruslan.

6

In recent code we don’t use Hook::LexWrap as it’s in most
case unnecesary. Something close to the following should work just fine:

require RT::XXX;
{
my $orig = RT::XXX->can(“method”);
*RT::XXX::method = sub {
my $self = shift;
return $orig->($self, @_);
};
}

My favorite is much the same, with the added benefit that you can die if
the API call is removed.

{
package RT::Foo;
no warnings ‘redefine’;

my $original = __PACKAGE__->can("bar")
    or die "API change?!  Can't find method 'bar' in ", __PACKAGE__;
sub bar {
    ...
    $original->(...)
}

}

7

Am 10.06.2013 20:36, schrieb Ruslan Zakirov:

see lib/RT/IR.pm in RTIR extension. We basicly wrap methods from
extensions’ primary file.

You use here Hook::LexWrap and I saw some commit comments that
Hook::LexWrap makes some troubles:
Remove Hook::LexWrap, and replace with a simpler glob manipulation · bestpractical/rt-extension-mergeusers@354edf0 · GitHub

RTIR’s usaged of Hook::LexWrap is on my short list of things to go
away. I haven’t found a need for lexical wrapping in RTIR yet, so it’s
mostly just testing after the removal.

-kevin