cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tomoki Tsuchida" <>
Subject Cocoon, Turbine, Jetspeed, etc.
Date Thu, 21 Dec 2000 19:59:37 GMT
Hi, this is my first message to this mailing list.  I'm a developer in a 
small Internet consulting company, and am currently working on our client's 
Intranet site.  Right now we are using JSP/servlets on WebSphere/Netscape 
Enterprise Server (backed by Oracle), but it's a huge mess.. no 
content/presentation/logic separation, no clear content management, etc.  
Which is natural, because they basically had only few month to add dynamic 
content (such as company-wide news page) to their mostly static site.  But 
they're giving us a little bit more time to totally rearchitecuture their 
whole system... and we are planning to start working on the rearchitecturing 
after we come back from our vacation :)  So I've been looking at different 
technologies that's available right now, and obviously I picked 
Cocoon/Turbine as one of my choices.  My plan is to learn enough about this 
technology so I can convince my boss how awesome they are =)

I'm not sure if it's polite to ask so many questions in a mailing list, but 
please bare with me...

How are Cocoon and Turbine positioned in terms of c/l/p separation, or at 
least how *should* it be positioned?

I've downloaded both Cocoon and Turbine and, as a developer, tried to write 
some 'web applications' on both (not on the same Tomcat :P).. but I'm really 
confused as to how to do the things 'the right way'.  It seems like both can 
get the same job done..
For Cocoon, I understand the flow of the things is:

client request --> 1) XML w/ custom taglib (content)
               --> 2) Cocoon processes logicsheet in taglib (content)
               --> 3) Cocoon processes resulting XML w/ XSL(presentation)
client HTML    <--

In terms of development, the content people will write (1) with XML & custom 
tags only, the programmers (me) will write logic (2) with <xsp:logic> inside 
<xsl:apply-template select="mytag:doSomething">, and the designers will 
write presentation (3) with XSL and HTML. (Is this correct?)

After writing a simple "poll" application that gets question & answer text 
and stores vote counts from db (mySQL) using this model, I had the following 

a) The content and the rest are separated very well.  Basically poll.xml 
will have something like:

   <question>What is your favorite color?</question>

for a 'static' (i.e. no db-backed content) XML, and if I felt like pulling 
it out of db, then:


so all I need to tell the content person are different XML tags.

b) On the logic section (poll.xsp.xsl), things are very messy... I liked the 
<sql:> tags, but it seemed that they'd have to be in the 'content' XML to 
work... for example:

    <sql:query>SELECT question FROM tbl_questions</sql:query>

But of course, I don't want my content person to have to know DB related 
parameters:)  Hence the custom taglib above.  But I couldn't make Coccoon to 
process XSP *and* SQL tags in the same XSL page... and even if it did, I 
didn't think the SQL tags are easily integrated into logic (how do I 
maniuplate the result and UPDATE the database??)  The thing I ended up doing 
was to hard-code everything, i.e.:

<xsl:template match="poll:getQuestion">
    try {
      rs=stmt.executeQuery("SELECT ...");
      //Do all I want to do with the result
    } catch (Exception e) {
     // all the good old exeption handling
    } finally {
     /// all the good old cleanup

Which is, IMO, not really better than JSP (and I don't think I can freely 
'mix' XML, <![CDATA[ ]]> is no better than <% %> :P).  I also really wished 
some of Turbine's nicer facilities (db wrappers, etc.) were there...  Is it 
possible to include Turbine's library and use it there?

c) On the presentation XSL, things are pretty straightforward.. The 
designers would only need to know what XML are coming in, and produce 
resulting HTML using XSL.  The learning curve for XSL syntax will be *very* 
high, though... XSL seems to be more like a programming language rather than 
templating language, which is good for people like me but I'm not sure about 
designer people.  Also, I was wondering what to do for *static* contents 
with lots of variable design elements.  XML would be a beautiful solution if 
all of the items have common 'looks', but what if designers want separate 
looks for each item?  I would imagine that either XSL would be very 
complicated (for news item1, put picture on the right, for news item2, put 
picture to the left... etc.).  Should <fo> be considered part of the 

For Turbine, I couldn't really make it work due to my lack of knowledge 
(where do I put my own class that extended Screen, and how do I access 
it???), but as far as I can see the flow of things is:

client request --> Templating engine (WM, V)
               --> My own action (logic/content)
                   <-- Templates (presentation)
client HTML   <--

As a programmer, this design seems to be very nice, since what I'd have to 
do in the previous "poll" application would be:

1) Subclass Screen to make my own screen that pulls question text out of db 
(or load a 'static' question file)

2) Designers will design the template for view, like:


Although I don't really know where the separation between content and logic 
will come in in this model, it will definetely be much simpler to 
incorporate existing static pages because all you have to do is to make 
templates for the common elements in the html.  Of course I would be losing 
portability of XML/XSL in the process, but I don't know how much work it 
would be to make all static HTML into XML/XSL pairs, while preserving all 
the 'design' considerations..  I'm not even sure if I should be comparing 
XSL to a templating system, but as far as I can tell XSL is just as good (or 
bad) as WM or Velocity, maybe somewhat more functionality for somewhat more 
verbose syntax.  I would also be happier writing separate actions in 
separate java classes, as opposed to inside of <xsl:logic> section (perhaps, 
I don't know yet since I haven't be able to code in Turbine environment :)) 
I wouldn't be adding XMLNodes in the java code though :)

So, the bottom line is, what is the best way to take in the 'best of both 
worlds' to organize a site with both static content and dynamic content 
(with web applications)?  In Jetspeed architecure, what exactly are they 
doing with Cocoon and Turbine?  Both architecturely and programmatically I'm 
having trouble making them work for each other (why does Cocoon have Turbine 
DbPool class and not the rest of Turbine classes?)

I know it's a lot of questions and are probably not simple to answer either, 
but I would really appreciate any input to any part of my questions.


Get your FREE download of MSN Explorer at

View raw message