MarkW, IMO, we use xslt a lot in DSpace at a multitude of levels. Its very flexible and the inputs and outputs can be extremely flexible as well. Switching email templates to a xslt strategy takes advantage of an application stack already present in DSpace and helps keep our use of multiple programming languages at a minimum (and I'm not talking strictly about the XMLUI in this case, but the entire packager/crosswalk framework that is core to DSpace leverages XSLT, as well as OAI). The argument can be served that we want to minimize the complexity of using multiple templating languages to keep the amount of cross language learning developers need to do at a minimum.
A simple strategy would generate an input document that details recipients, senders, dynamic Item, workflow data needing to be communicated. and the output would be the content of the body of the email message. The xslt could even use the literal result element approach [1] and simply be an html (xhtml) document that could easily be edited in common html tools. MarkD [1] http://www.w3.org/TR/xslt#result-element-stylesheet On Sun, Jul 26, 2015 at 12:06 PM, Mark H. Wood <mw...@iupui.edu> wrote: > The email templates haven't kept up with recent developments in > DSpace. I think we need to re-examine the problem. > > My starting point is that my organization wants to send out > "submission accepted" emails which contain generated DOIs rather than > plain Handles, when DOIs are available. I've hacked the workflow code > to add an email parameter that contains the DOI if present, else the > Handle, but it occurred to me that this is a customization that ought > not require rebuilding DSpace; can't we find a way to specify such > things by configuration, without adding dozens of parameters and yet > never quite having everything that might reasonably be wanted? > > My first thought was to allow "parameters" that are small Javascript > snippets. We could do that, but I ran into problems: at least one > distribution doesn't include a Javascript engine with a popular JRE, > so actually using JSR 223 scripting requires some nontrivial work. In > addition I later came to view this as a troublesome approach, as I'll > explain below. > > My second thought was to enhance the templating language. This led me > to consider that we perhaps really ought not be maintaining our own > templating language, but instead use something that lots of other > people use and would maintain for us. It might already provide the > necessary facilities for making email template substitutions more > flexible. > > I took a look at StringTemplate. It can't be used the way I wanted to > use it, but it turns out that this is by design, and Parr's paper: > > http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf > > convinced me that I should try harder to avoid mixing logic into > something like an email template. I'm powerfully attracted by the > idea of giving the template design to the people who care about the > content of the email, and having developers just support them with > data from which they can make simple textual substitutions. I feel > that programmers shouldn't be writing letters to end users. > > So, at the moment I've turned back to the problem of providing a > scripting language to make the provision of template parameter values > more flexible, but separating that from the actual templates using > simple named parameters. Then administrators can manipulate email > texts without having to deal with script code, and coders can support > administrators without having to touch the templates, so long as they > can agree on a set of names and what they mean. > > One interesting problem not addressed in the paper (so far as I can > see) is that our universe of desirable parameter values (object > metadata) is *extensible at runtime*. We don't know what a given site > may have in the way of metadata, because a site can invent new fields > and even schemae. Because most metadata fields are optional, it seems > to me that we also need conditional structures when deriving a > parameter's value. Hence I see a need for scriptability. > > Comments? > > -- > Mark H. Wood > Lead Technology Analyst > > University Library > Indiana University - Purdue University Indianapolis > 755 W. Michigan Street > Indianapolis, IN 46202 > 317-274-0749 > www.ulib.iupui.edu > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel > > -- [image: @mire Inc.] *Mark Diggory* *2888 Loker Avenue East, Suite 315, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
