On Sun, Jul 26, 2015 at 01:51:20PM -0400, Mark Diggory wrote: > 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.
Minimizing dependencies and the knowledge required to use them is attractive. But the more I've thought about this, the more I want to be able to just hand the boilerplate text over to the non-coders who care what it says. Turning the message texts into XML probably makes that a lot more difficult. I'd like to see a clear separation of concerns between the committee which wordsmiths the message body, and the coders who implement the calculation of the required parameters. Consider the value of loading the boilerplate into a <textarea/> on an administration page so that the committee members can edit it live whenever they feel the need. Now imagine that it must be a well-formed XML document. > 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. If we're going to precalculate every possible parameter, then we may as well just set them as global parameters on the Transformer and then process the unmodified template using the unmodified transform. There's no need to generate the input document; just read it from storage. But I think XSL is at the same time too powerful in some ways and not enough in others. It tempts us to introduce lots of logic into the templates, which makes them harder to read and understand, but we don't really need to see the logic there. At the same time, the XSL processor doesn't have direct access to the metadata; we must spoon-feed it everything we think might be relevant and hope that we missed nothing important. The latter is why I was drawn to JSR 223 scripting: it neatly ties script code to Java objects. -- 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
