cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian <>
Subject Re: Fundamental Cocoon Philosophy Question
Date Sat, 11 Sep 2004 16:21:16 GMT
Thanks Tony, I appreciate your opinions.  The
divisions I was referring to regard the blocks.  My
suggestion would be that the blocks are downloaded
separately from the main Cocoon kernel with some basic
samples.  Also the blocks should have a separate
section on the site for downloads, docs, etc.  IMHO,
this would clearly show to potential users that a
Cocoon kernel exists and that several "apps" are built
upon that kernel.  I feel this is not clear, although
I have understood it.  BTW, hot swapping blocks sounds
   As far as the Forms are concerned, I do feel the
current incarnation as being the most stable and
developed attempt so far.  I believe it would most
likely stick around.  Either way I am mostly concerned
about developing in almost pure XML and in a newly
developed tech.  The stability and longevity of
projects like Struts seem to be the way to go. 
Cocoon's kernel is great, but I am concerned with the
maturity of the peripherals on top.  I look forward to
seeing how Cocoon's webapp framework evolves...mostly
I'll be watching for the Forms, Flow, JSR-168, and
(hopefully one day) workflow management system
integration.  Oh well, I need to continue comparing
the pros and cons thoroughly before making my decision
to stick with Cocoon.


--- Tony Collen <> wrote:

> Comments inline...
> <snip>
> Julian Wrote:
> >  I think in
> > 
> >>order to feel comfortable adopting these
> >>implementations, I need to believe they won't be
> >>scrapped and that there is unifying
> model/philosophy
> >>behind where/what Cocoon will become as it further
> >>matures.  Perhaps many of these projects should be
> >>spun out of Cocoon into subprojects rather than
> >>calling them blocks....akin to the Lenya app.
> I don't see CForms going away anytime soon, nor do I
> see Flowscript. If 
> you're really concerned about where Cocoon is going,
> please join the 
> -dev list and start a conversation about it.
> <snip>
> >  **As it
> > 
> >>stands the Cocoon project is becoming too big and
> >>confusing as to what it really is.**  This is a
> burden
> >>for neophytes.  From the site's from page:
> >>
> >>"The Apache Cocoon Project is the open source
> >>community project developing Apache Cocoon and
> >>Cocoon-based application frameworks."
> >>
> >>I can accept this, but where is the division that
> >>creates consumable parts?
> > 
> > 
> > What division are you speaking of?  The developers
> recognize that Cocoon
> > needs to allow dynamic loading of "blocks" and are
> actively working on
> > that.  Or maybe that isn't what you meant.
> Yes, there are plans to allow Cocoon to have
> hot-swappable pieces.  This 
> is what's known as "Real Blocks," and it's been in
> the works for quite 
> some time now.
> See
> for more information.
> Julian Wrote:
> >>Finally, running an app written mostly in xml
> makes me
> >>shake in my boots.  I think Cocoon is great, but
> >>sometimes too much emphasis seems to be put into
> XML.
> Ralph's Reply:
> > Why?  (BTW - Cocoon doesn't really run on XML. It
> runs on SAX events). 
> > This "feature", in my mind, is one of its greatest
> strengths as I find I
> > can customize almost anything.
> Yep, and remember, the XML publishing is just one
> aspect of it all. XML 
> is good for publishing... the view. Of course, you
> shouldn't rely on XML 
> for stuff like Flow Control or backend stuff, which
> is why we have 
> Flowscript and the OJB or Hibernate integration
> writeups...
> >>I hope this helps rather than sounding like
> endless
> >>ramblings.  If it is the latter, please accept my
> >>apologies, but I fear that Cocoon is outgrowing
> the
> >>garden.
> Trust me, people have felt this way for years :)
> The best way to help is to contribute to the
> project.  Like I said, 
> subscribe to the -dev list and join the
> conversation.
> Tony
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Live simply so others may simply live. 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily" 
-William of Occam

Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!

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

View raw message