cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian <cerebr...@yahoo.com>
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
great!
   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.

Thanks,
-Julian

--- Tony Collen <colle006@umn.edu> 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
>
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109362470725423&w=2
> 
> 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:
> users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail:
> users-help@cocoon.apache.org
> 
> 

=====
Live simply so others may simply live. 
 
-Ghandi 
 
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!
http://promotions.yahoo.com/new_mail

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message