cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Terence Kearns <>
Subject Re: JXTemplates - what's in a name?
Date Tue, 04 May 2004 01:02:54 GMT
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 

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 ). 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:
For additional commands, e-mail:

View raw message