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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
