You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Derek Hohls <DH...@csir.co.za> on 2004/05/03 14:28:29 UTC

[Summary] Cocoon: Language Babel -or- Database Development Platform

The thread on this topic refers
(http://marc.theaimsgroup.com/?t=108315683000003&r=1&w=2), where I
highlighted some concerns about understanding the supposed "best path"
for developing complex, interactive (2-way) database applications, using
some of the newer Cocoon technologies PLUS various add-ons, such as
Hibernate.

Comments/suggestions were as follows (with some 'direct quotes'): 

*  'Maybe Cocoon is just perfect for [a "real" web application].  I
would like to think so, but I certainly haven't seen examples, and the
existing documentation feels pretty thin..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
viability.  It might be that everything I need is out there, but it all
feels scattered.'

* It was suggested that an "out-of-the-box Hibernate/CForms binding"
(or some other O/R framework) should be a requirement.  The response was
that an intermediate collection should be created, so that *additional*
logic, like extra validations, could be done before passing the data
back to the persistence layer.

* Other comments were made to the effect that tools such flowscript are
'revolutionary but too complex and too young'; CForms 'are too complex
and not Production-Ready' and that complex apps are hard to debug
because of verbose logging and lack of an IDE.

I get the sense that Cocoon is poised on the edge of big "paradigm
shift", perhaps similar to that in the jump from 1.x to 2.x (the thread
on JXT vs XSP also bears this out).  Could it be that we are "almost
there" and that is why there is a sense of frustration in knowing that
things could/should be possible but without the crucial "missing
pieces".   The perception of complexity is, of course, related to the
degree to which these things can be understood, which in turn relates to
how well concepts/application are communicated...

* Ugo jokes that he will write a book on "Developing Web Applications
with Apache Cocoon and Hibernate".  Of course, very few of us have time
to write a whole book - but even a short chapter/outline of
approach/recipe will be of huge help to those who are starting from
scratch!  It was commented that 'A better repository of user-oriented
tutorials would be wonderful... [to] pull together several concepts,
highlight new features, and spark new ideas.' 

In general, I think that the comment : 

'Cocoon has a really good, quirky, "think different" attitude that
other frameworks like struts or turbine lack. But very little of the
documentation reflects this attitude.  The official cocoon site doesn't
reflect this feeling either.  The attention of the Cocoon user community
is decentralized, spread among the official site, the Wiki, and the user
list.  So the documentation feels spread apart too, and there is a lot
of emphasis on nuts and bolts, but not so many "bigger picture"
tutorials that teach and encourage Cocoon design methodology.'

is very true. For me, moving Cocoon up to centre stage will require
that those already in the know (such as Ugo?) reach down to help up
those wanting to do bigger and better things.  The more Cocoon can be
seen to do (not just have a *potential* to do), the more it will draw
the attenntion of the OS community; this will be a self-reinforcing
process as more people will then be available to develop better apps and
share their ideas etc.  Otherwise, we are at the risk of having a
brimful cup of strong tools and very few who understand how to use that
power correctly.  And that would be very sad.

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