Mailing List Archive: Request Tracker: Devel

plugins and _Vendor files

Index | Next | Previous | View Threaded

bradleyb at uw

Jun 10, 2013, 11:31 AM

Post #1 of 7 (173 views)
Permalink

plugins and _Vendor files

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

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

trs at bestpractical

Jun 10, 2013, 11:34 AM

Post #2 of 7 (162 views)
Permalink

Re: plugins and _Vendor files [In reply to]

On 06/10/2013 11:31 AM, Bradley Bell wrote:
> 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.

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

ruz at bestpractical

Jun 10, 2013, 11:36 AM

Post #3 of 7 (163 views)
Permalink

Re: plugins and _Vendor files [In reply to]

On Mon, Jun 10, 2013 at 10:31 PM, Bradley Bell <bradleyb [at] uw> wrote:

> 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.

cloos at netcologne

Jun 10, 2013, 11:22 PM

Post #4 of 7 (153 views)
Permalink

Re: plugins and _Vendor files [In reply to]

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:
https://github.com/bestpractical/rt-extension-mergeusers/commit/354edf0

Chris

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

ruz at bestpractical

Jun 11, 2013, 6:02 AM

Post #5 of 7 (154 views)
Permalink

Re: plugins and _Vendor files [In reply to]

On Tue, Jun 11, 2013 at 10:22 AM, Christian Loos <cloos [at] netcologne>wrote:

> 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:
> https://github.com/bestpractical/rt-extension-mergeusers/commit/354edf0

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.

trs at bestpractical

Jun 11, 2013, 9:28 AM

Post #6 of 7 (153 views)
Permalink

Re: plugins and _Vendor files [In reply to]

On 06/11/2013 06:02 AM, Ruslan Zakirov wrote:
> 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->(...)
}
}

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

falcone at bestpractical

Jun 11, 2013, 9:49 AM

Post #7 of 7 (152 views)
Permalink

Re: plugins and _Vendor files [In reply to]

On Tue, Jun 11, 2013 at 08:22:16AM +0200, Christian Loos wrote:
> 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:
> https://github.com/bestpractical/rt-extension-mergeusers/commit/354edf0

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads