JXTemplates - what's in a name?

[Derek Hohls <DH...@csir.co.za>]

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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: JXTemplates - what's in a name?

[Terence Kearns <te...@isd.canberra.edu.au>]

I'm new to cocoon and JXTs so what I know is only what I have read on 
the website and what I've done so far with a cocoon app I've taken over 
development of. I will make some general comments on the ideas you've 
raised.

I wouldn't get bogged down in the whole "purity" thing with whether or 
not a template is a "true template". For me, the important thing is 
separation of concerns. As you point out, XSLT provides enough 
facilities in the specification to create the necessary contracts for 
separation of concerns. For me, it's the only templating system I need 
and I choose it because it is a widespread cross-technology standard.

Being a cocoon newbie, I'm questioning the need to use XSPs because I 
see them as a way to loose many of the bonuses that come with OO in 
terms of using popular industrial tools like JavaDoc and Junit. Although 
I started my web development career with ColdFusion, I'm not a big fan 
of the tags and code mixture when it comes to creating a controller (in 
the MVC sense) or writing business logic.

I'm thinking I'm probably gonna write all my apps using custom generator 
classes and just ignore XSPs. But that's just me. Some would argue that 
XSPs are easier and "more rapid" but I think they just create an extra 
layer of maintenance in your java application. I've just taken over 
development of an existing cocoon app here at work so it looks like I'll 
be writing XSPs in the short term, but they are not for me.

Generally, as far as your discussion goes, I don't like using text-based 
templates anywhere near my business logic - ie, I don't like using the 
templating facilities of JSP, XSP, ASP, PHP, or ColdFusion. My 
experience is mainly with PHP, and I tend to write in an OO way - using 
the standards based DOM API to build up my content, and then I use an 
XSLT processor to orchestrate the view (with XSLT stylesheets). I think 
this concept in general is very simple but it is a scalable one with 
easy maintenance.

(I've written a PHP framework (XML Application Objects) which is on hold 
while I learn cocoon http://xao-php.sf.net ). Maybe when I get more 
experience with cocoon, I will port XAO as a set of cocoon generators. 
As it stands, it's already easy for me to integrate XAO applications 
into coocoon as it is easy to pull untransformed content into the 
sitemap -- especially in the contenxt of aggregation. Same is true the 
other way around. XAO can easily "consume" XML from a cocoon app with 
one line.

So yeah, all I need is the DOM standard for content generation, and the 
XSLT standard for formatting.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: JXTemplates - what's in a name?

[Bruno Dumon <br...@outerthought.org>]

On Mon, 2004-05-03 at 14:22, Derek Hohls wrote:
> 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).

How does that differ exactly?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

AW: JXTemplates - what's in a name?

[Marco Rolappe <m_...@web.de>]

hi derek,

I alse read that paper and agree that it was revealing. it also made me
rethink view generation (the bad symtpoms had of course already occurred to
me).

my current idea (pretty blurry ATM) is to create a stripped down version of
the JXT generator (remove the 'power features') and provide it with 'view
contexts'. there would be a 'facility' (kind of factory) which would return
a 'view context' for a specified view identifier. now the simple JXT
generator would have all it needs to 'fill the holes'.


> -----Ursprungliche Nachricht-----
> Von: users-return-66947-m_rolappe=web.de@cocoon.apache.org
> [mailto:users-return-66947-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Derek Hohls
> Gesendet: Montag, 3. Mai 2004 14:23
> An: users@cocoon.apache.org
> Betreff: JXTemplates - what's in a name?
>
>
> 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.
>

<snip what="almost everything">;-)</snip>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org