cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Fitzgerald <>
Subject Re: Cocoon: Language Babel -or- Database Development Platform ?
Date Wed, 28 Apr 2004 20:05:31 GMT
Derek, you've elucidated what I'm sure is a recurring tension for many 
cocoon users.  I really identify with you.  My group has been using 
Cocoon for a little over a year now to publish a huge set of XML 
content, translated and localized for several languages.  Cocoon has 
been an excellent choice for such a project.  But if I wanted to take 
it further, like if I were to develop a "real" web application like you 
describe, I know I could do it with Cocoon, but the path is definitely 
not so clear.  Suddenly Cocoon feels stretched, out of place, and less 
elegant.  Maybe I am wrong.  Maybe Cocoon is just perfect for such 
applications.  I would like to think so, but I certainly haven't seen 
examples, and the existing documentation feels pretty thin.

I think that Cocoon *is* on a cutting edge.  It is altogether a very 
different design paradigm, and it is still feeling its way.  I am quite 
confident that the basic elegance of Cocoon's pipeline/component 
approach is here to stay.  I'd also put my money on Flow and 
continuations.  Beyond that, some of these other pieces will succeed 
and others won't.

A big part of the equation is documentation.  The wiki and docs for 
sitemap design, components, and design patterns are all good.  The 
newer pieces are understandably less documented.  Like a lot of things, 
open source documentation is a bootstrapping process: better 
documentation on a component means that more people will learn to use 
it, which means more users, which eventually means more experts, which 
then translates to even better documentation.  So new components with 
little documentation take a while to get going.  And without good 
documentation, it's hard for most potential users to determine a tool's 


On Apr 28, 2004, at 5:50 AM, Derek Hohls wrote:

> And in the beginning, Stephan Mazocchi created Cocoon.  It was based on
> XML - Programmers used Java and Users used XSLT - and it was simple but
> good.  And it worked and applications were delivered.  Everyone
> understood and everyone was happy.
> And then the Users spoke up, saying that Web Publishing was complex and
> that more Features were required.  And so the Pipeline and Pipeline
> Components and The Sitemap were created, and they too were based on XML
> and Java and they were good.  And, because more Logic was required, XSP
> was created - a Marriage of XSLT and Java - and it too worked, and
> applications were delivered.  Although some scorned XSP, preferring the
> purity of the Pipeline Component, most understood and most were happy.
> And the Users demanded more; saying that Web Publishing was not enough
> and that Web Applications, requiring yet more Logic and Functionality,
> were required.  And so were created Cocoon Forms (oft-called 'Woody', 
> to
> the confusion of the uninitiated) and Flowscript, based on JavaScript.
> While some now wondered about the introduction of yet another Language,
> some understood and some seemed happy.
> But many still spoke up, saying that Cocoon was but one Framework among
> many and so insufficient on its own to deliver Real Applications.  And
> so a great Babel of other languages and tools were taken up and other
> approaches, based on the Old Ways of Templating Languages (up to now,
> considered a heresy amongst the Cocoooners), were incorporated.  Few 
> now
> understood the Great Cocoon Universe and many were confused.   And the
> Users wondered why Developers spent all their time learning these many
> and arcane Ways and why applications took so long to deliver...
> OK - aside from the rather poor parallel to the original, I guess I am
> beginning to be concerned about how much is seemingly required to get
> going and __keep__ going with Cocoon-centred apps.
> A brief time capsule for background: I have worked with Cocoon since
> version 1 and, while I have not made extensive use of many of its
> features, I have been happy to know that these are there and can be
> called on as my needs grow.  The primary reason I started with Cocoon
> was that it gave me a way to readily work with XML, which allowed me to
> decouple HTML layout from source data.  This single aspect meant I 
> would
> never have to handcode websites again and made templating approaches
> such as JSP and ASP archaic and redundant (and I am constantly 
> surprised
> they still seem so popular).  This was rapidly followed by the need to
> publish database data; again, the decoupling provided by XML and the
> Cocoon framework was a pleasure to work with, and ensured effective,
> even parallel, application development.
> I am now at the point where I am faced with the possibility to design
> and deliver a large, complex, long-term, database application via a web
> front-end (as opposed to a traditional client-server front end, written
> in a RAD GUI, which is what I have done up to now).  I believe that a
> web-based solution is the correct long-term approach, even if some of
> the technology seems a little clunky right now.  To date I have been
> content with using XSP / ESQL for small, interactive DB apps, and I
> _had_ thought that I should now have to learn Cocoon Forms (or Woody)
> and Flowscript, xReporter and, possibly, Java Beans for logic - 
> somewhat
> of a learning curve for me but also not impossible.   However, recent
> discussion on this topic shows that some developers believe a whole 
> slew
> of _other_ technologies (outside of Cocoon) need to be learnt and
> incorporated before one even starts with the design...
> So, my question is:
> *** Which solid, well-documented approaches, using primarily
> Cocoon-based mechanisms, exist to create complex database applications?
> These approaches need to be at least documented in a detailed article
> and, preferably, in a well-written tutorial/guide.
> ** My observation is - if such does not exist, and I still want a web
> front-end, should I be abandoning Cocoon and going for some old-style,
> template-based approach, using other frameworks such as Struts,
> Hibernate, Velocity, PHP etc. etc. [and, of course, the same question
> applies here - is there something well-documented which lays a solid,
> detailed foundation/guide for taking a developer through all this?]
> * My last thought is - if there is no well-explained answer to either
> of the above, does this mean we are on the cutting edge when it comes 
> to
> this type of work... because then I will at least know where I stand 
> and
> can, hopefully, decide accordingly!
> Thanks in advance for any and all observations/comments.
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message