Refactoring RT::Tickets_Overlay.pm

RT Developers
1

In developing Asset Tracker I have “borrowed” a lot of helper
methods from Tickets_Overlay. It would seem that many of these
methods would be more appropriately placed in RT::SearchBuilder,
or a class that ISA RT::Searchbuilder and then subclass RT::Tickets
from that.

Does this make sense?

Which of the two possibilities from above would be preferred?

Would a patch toward this goal be welcomed?

-Todd

2

In developing Asset Tracker I have “borrowed” a lot of helper
methods from Tickets_Overlay. It would seem that many of these
methods would be more appropriately placed in RT::SearchBuilder,
or a class that ISA RT::Searchbuilder and then subclass RT::Tickets
from that.

Does this make sense?

Depends on what they are. What are they? :wink:

3

In developing Asset Tracker I have “borrowed” a lot of helper
methods from Tickets_Overlay. It would seem that many of these
methods would be more appropriately placed in RT::SearchBuilder,
or a class that ISA RT::Searchbuilder and then subclass RT::Tickets
from that.

Does this make sense?

Depends on what they are. What are they? :wink:

For starters, all the helper functions in the dispatch table:

&_EnumLimit,
&_IntLimit,
&_LinkLimit,
&_DateLimit,
&_StringLimit,
&_TransLimit,
&_TransDateLimit,
&_WatcherLimit,
&_WatcherMembershipLimit,
&_LinkFieldLimit,
&_CustomFieldLimit,

4

For starters, all the helper functions in the dispatch table:

&_EnumLimit,
&_IntLimit,
&_LinkLimit,
&_DateLimit,
&_StringLimit,
&_TransLimit,
&_TransDateLimit,
&_WatcherLimit,
&_WatcherMembershipLimit,
&_LinkFieldLimit,
&_CustomFieldLimit,

Those really make the most sense if you’re also porting Tickets_Overlay_SQL up.
and at that point, it should likely become a DBIx::SearchBuilder mixin.
This is also something I’d love to hear comments from Robert on.

Jesse