An April 2004 post pointed me to Terence Parr's article on "Enforcing Strict MV Separation in Template Engines". (see article link at: http://www.stringtemplate.org ). This is a fascinating read and, to me, a classic in the field.
What I learnt (amongst other interesting stuff) is that a "true" template ONLY provides a view on the data: it should not incorporate ANY logic (apart from the need to understand standard data structures; refer to other templates; and test for the existence of data) and so not be subject to any changes in the underlying model. This definition seems to differ from the rather loose term used in the Cocoon community; for example, Bruno says "a template is just an easy way to create a custom generator". (ref: http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108317864027176&w=2). Obviously, the word template has differing connotations in different circumstances, which is unfortunate, as it makes hard to discuss and compare concepts and approaches. Two issues immediately spring to mind here, and I'd appreciate some thoughts/comments from those with more experience: 1. Given that the whole emphasis in Cocoon is on SOC, what are the implications for the role of JXTemplates (JXT) in the overall architecture? Certainly, JXT does not qualify as a "true template" in Parr's definition (as it's easily broken by changes in the underlying data model). Some - Peter (in thread: http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108332731908424&w=2) and Bruno (see above) - suggest that the role of JXT should be as a better replacement for XSP; in this role it serves as a data generator and therefore it's irrelevant as to whether or not it uses any logic. Of course, downstream, data manipulation takes place via XSLT, which *also* does not qualify as a "true template". Nonetheless, at least a contract of agreement between the two steps can be enforced by XML Schemas (or equivalent - see more discussion in this article http://www.xml.com/lpt/a/2003/11/12/cocoon-eai.html ), thereby shielding any XSLT logic from underlying model changes. Arguably, though, its significantly harder for a graphic designer to work with XSLT (even some programmers struggle with it) and so a "true template" facility is really missing in this picture. Other - Ugo (in thread: http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=108272253016660&w=2) - seem to imply that the role of JXT *is* in creating the view, although I do not understand the details of how this is proposed to work. I tend to favour the first option, given the assumption of the role that a "true template" should play. 2. What are the possibilities for incorporation of the "stringtemplate" template engine, designed by Parr, into Cocoon? I think the major challenge is a conceptual difference. Stringtemplate does not work with XML; it assumes that the data that it references is created in a directly-referenced data object (say, from a Java-based generator). ST is an absolutely minimalist "language" - more a set of very simple notational elements, deliberately designed to be used by a graphic/web page designer and NOT a programmer. Given Cocoon's "open framework" and "tools agnostic" philosophy (which allows it to incorporate "best of breed" tools and concepts), it should be possible to create the equivalent of ST for Cocoon. The "template language" would need to be able to locate data items via an Xpath expression; and it should be possible to create a mechanism which provides a way, as ST does, to work with hierarchical structures (as XML is, of course). From a basic reading of JXT, it seems even a "stripped down" version of this might suffice? This would serve those applications that need to allow a graphic page designer, or end user, access to display data in a manner they choose, without any assumptions about, or impact on, the underlying model, and the means by where the data structure is generated. Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
