Action Trigger may benefit from sharing templates with OPAC, etc.

[Dan Wells]

* Evergreen master

We had a local request to add call number and location information to records emailed from the TPAC. Doing so is possible, but it involves duplicating a lot of display logic from misc_util.tt2.

Right now, Action Trigger stores all of its templates in the DB, while the OPAC templates are in the filesystem. From what I have seen so far, they are not easily shared. Some possible steps which would bring these areas together might include:

1) Implement a common INCLUDE_PATH. If the Template processors for each service knew where to look, it should be possible to even use filesystem templates (or template fragments) within the DB templates (e.g. using PROCESS).
2) Create a shared library of template/display functions. Right now, Action Trigger has a collection of "helpers", while TPAC hangs some methods on the 'ctx' object. We may want to abstract these out such that they could be attached to an object used in either environment.

Discussions relating to slightly different angles on this bug are also in progress on bug #1407504 and bug #1347774.

[Galen Charlton (gmc)]

I agree that it's worth considering ways to share relevant template blocks and template functions between public catalog and A/T (and KPAC, for that matter). In particular, sharing helper functions could be an easy win.

However, I'm not keen on the notion of having the A/T template processor look to the filesystem for templates: doing so would complicate setups that use standalone database servers.

[Jason Boyer (jboyer)]

Being a system that runs a separate database server I'd like to +1 Galen's comment. Something that might work would be to be able to include a template from the database that defines these shared blocks using PROCESS either with a database id (not ideal) or template name. This way the opac could import the shared blocks the same way the in-db templates do and there's no need to worry about where any particular files are located. I don't know enough about TT2 at the moment to know whether or not this is a major undertaking or an impossible one.

[Galen Charlton (gmc)]

Storing template fragments in the database for use by the OPAC is doable. For that matter, with some effort, it would be possible to have the database be a provider for *all* of the OPAC and KPAC templates, which could have some advantages for farming out maintenance of tweaks in a consortium. But that's probably a separate discussion for the future.

[Dan Wells (dbw2)]

Thanks for the discussion, folks. We run a separate DB server in production as well (and I think most do), so my spitballing could have used some more chewing in that regard :)

Seems like some consensus is building to first get some more of the utility logic out of the templates and into the Perl layer (as suggested in bug #1407504), then make this library/module available to the various environments. This looks like the overall easiest path to something usefully better.

[Mike Rylander (mrylander)]

I feel pretty strongly that if we're looking to centralize template-embeded logic for use in TT, we should just do it the Right(tm) way via:

  http://www.template-toolkit.org/docs/modules/Template/Plugin.html

My strong feelings on that matter include moving all the random "helper" stuff from the TPAC into proper TT plugins.

We can use any prefix we like, or just install into Template::Plugin -- that's just a one-line change/addition at the TT processor call sites -- but we really shouldn't be inventing our own way of injecting OO-ishness into TT.

Just putting my $0.02 out there... :)

[Jason Stephenson (jstephenson)]

As a not in favor of Mike's suggest regarding TT Plugins, part of my original solution to bug 1208875 included a simple CSV plugin for TT.

[Jason Stephenson (jstephenson)]

That should have been "as a note in favor" and not "as a not in favor." I should proofread short comments better.

In other words, I think TT Plugins are a good idea.

[Dan Wells (dbw2)]

Thanks again, all, for more useful context. I agree we don't want to invent anything, but it does look like we may need to un-invent in a few places (e.g. ctx.get_org_setting() (and other ctx.get_* methods) in TPAC, or helpers.get_copy_bib_basics(), etc. in action trigger templates). Are these the sorts of things we want in proper plugins? I think that's what we're getting at.

[Mike Rylander (mrylander)]

That is, indeed, what we're getting at, at least as far as I'm concerned.

I think we can pretty easily absorb what exists today in proper TT plugins, or wrap the existing code in an appropriately shaped envelope, while injecting "ctx" or "helpers" objects for backward compat (at least for a few versions).

A main design goal, IMHO, should be to retain the benefit of a cached singleton where the template doesn't specify parameters on the USE line, but allow an OO-ish instance of relevant interfaces (primarily what we inject as "ctx" today) in template-defined contexts. This will make sophisticated templates in the A/T world simpler to structure, and the TPAC could use that mechanism in some situations where either staff or patron context could apply, and the user selects one or the other.

Thanks, all!

[Jason Stephenson (jstephenson)]

I don't think sharing templates between the OPAC and action trigger is such a great idea today.

I do think that having a configurable include path for common action trigger template elements is a good idea.

I don't think it will complicate things any more than using custom filters does. The filters have to be present on the servers where action_trigger_runner.pl runs and so would the extra templates. If you're using NFS, stick them there, or plop it in /openils/conf/templates or something like that.

Plugins might be nice, too, so we could add a configuration option for custom plugin locations while we're at it.

I also think that what I am describing possibly warrants a different bug, unless everyone is OK with this on being hijacked.