Sorry, I forgot to include the list.On Thu, 9 Oct 2003, darren chamberlain wrote:
- Alex Porras [2003-10-09 13:18]:
Can someone point me to some documentation for extending rt3 classes?
The *_Local.pm files are where you would add your local changes. If
the _Local.pm file doesn’t exist, you can simply make it. The end of
each .pm file has something like:
eval "require RT::Tickets_Local";
if ($@ && $@ !~ qr{^Can't locate RT/Tickets_Local.pm}) {
die $@;
};
I did notice that. Maybe I’m confused with the purpose of the _Overlay
and _Local structure. If I don’t want the functionality to affect tickets
themselves, how would I do that? With subclassing, I could create a class
just like ticket and have the web inteface use it, and ticket would be
left alone. However, if I create Ticket_Local.pm it will also affect the
parts that use Ticket.pm.
–Alex
I’m assuming the database table that your using will mirror that
RT3->Tickets.
I BELIEVE that you can subclass the RT::Ticket table with no problems. What
you’ll actually be subclassing is the aggregate of RT::Ticket and
RT::Ticket*_Overlay. Since the process of resolving the inheritance tree
involves the full resolution of the parents class, it will ‘pull in’ all of
the overlays and what you’ll actually be overriding are those overlay
methods.
Basically, you can think of the Ticket and all of it’s overlay modules as
one big module… With the order of resolution being defined in the file (I
don’t remember what it is off the top of my head).
I BELIEVE that this is how it works…
On a more general note, it will likely be MUCH easier to build your own
searchbuilder (or RT::Record) derived class instead of using RT::Ticket as
your starting point. Building a SearchBuilder class isn’t really that
difficult, and given the amount of overrides you would likely be doing by
overriding the Ticket class, you MAY be much better off inheriting from
RT::Record or Dbix::SearchBuilder::Record.
NickFrom: Alex Porras [mailto:alex@mediaocean.com]
Sent: Thursday, October 09, 2003 1:55 PM
To: RT-Devel List
Cc: darren chamberlain
Subject: Re: [rt-devel] extending rt3 classes? (fwd)
Sorry, I forgot to include the list.
I did notice that. Maybe I’m confused with the purpose of the _Overlay
and _Local structure.
These two techiques allow for replacement of object methods by the RT authors
(-_Overlay.pm) or your site (_Local.pm). I don’t think that’s what you
were asking how to do.
With subclassing, I could create a class
just like ticket and have the web inteface use it, and ticket would be
left alone.
I think you’re asking “How do I subclass an existing RT object?”? Since RT
just uses the native Perl OO facilities, “man perlboot” should help you
understand how that works. But simply put, your “RT::MyTicketLikeThing”
object would be implented in [prefix]/html/share/RT/MyTicketLikeThing.pm and
should contain the line “@ISA=qw(RT::Ticket);” which tells Perl what your
superclass is.
Ross A. Patterson
Chief Technology Officer
CatchFIRE Systems, Inc.
5885 Trinity Parkway, Suite 220
Centreville, VA 20120
(703) 563-4164
I’m assuming the database table that your using will mirror that
RT3->Tickets.
Correct. It would be based on that table. Initially, I had thought to
use the same table, as it seems to have a ‘type’ column, but I think I’d
be afraid to clash with actual ticket data, so I’m just going to use a
separate table.
I BELIEVE that you can subclass the RT::Ticket table with no problems. What
you’ll actually be subclassing is the aggregate of RT::Ticket and
RT::Ticket*_Overlay.
[snip]
Okay, that’s precisely what I wanted to find out. I had done a test, but
I later realized that I had done the test incorrectly, so the child class
wasn’t being used, which is what prompted me to wonder about the _Overlay
stuff.
On a more general note, it will likely be MUCH easier to build your own
searchbuilder (or RT::Record) derived class instead of using RT::Ticket as
your starting point.
Sound like you may be right. I went through some of the RT::Record code
and saw that an instance of RT::Record represents a single table. If I
wanted to write data to several tables, however, would it just involve
several different RT::Record objects (one per table), and have the calls
(i.e. Create) inside of $RT::Handle->BeginTransaction() and
$RT::Handle->Commit()/$RT::Handle->Rollback() calls?
I appreciate your help, Nick.
Regards,
–Alex
Hi Ross,On Thu, 9 Oct 2003, Ross Patterson wrote:
On Thursday 09 October 2003 02:54 pm, Alex Porras wrote:
I did notice that. Maybe I’m confused with the purpose of the _Overlay
and _Local structure.
These two techiques allow for replacement of object methods by the RT
authors (-_Overlay.pm) or your site (_Local.pm). I don’t think that’s
what you were asking how to do.
Oh, so it’s so you can make changes and not have to change the frontend
code as far as referencing package names. That makes sense. Okay, I’m
talking to myself now, so I’m going to shut up.
Thanks for helping clear that up.
–Alex
Alex Porras wrote:
Hi Ross,
I did notice that. Maybe I’m confused with the purpose of the _Overlay
and _Local structure.
These two techiques allow for replacement of object methods by the RT
authors (-_Overlay.pm) or your site (_Local.pm). I don’t think that’s
what you were asking how to do.
Oh, so it’s so you can make changes and not have to change the frontend
code as far as referencing package names. That makes sense. Okay, I’m
talking to myself now, so I’m going to shut up.
Thanks for helping clear that up.
*_(Overlay|Local|Vendor).pm files contain only functions which just
override subs in module that include them. So you never call Foo from
RT::Ticket.pm if RT::Ticket_Overlay.pm also contain sub Foo.
Also RT::Ticket_Overlay.pm does not contain ‘package’ directive so it is
same package as RT::Ticket.
Ok. Now if have to change any function of RT::Ticket code then you just
define it in RT::Ticket_Local.pm and it works instead of RT’s one. But
you must save API of this function otherwise you could break RT’s logic
at all.
Also you could add any new function with any API and call it on any
RT::Ticket instance, but I recommend you follow RT Coding Style.
Good luck. Ruslan.