cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <DHo...@csir.co.za>
Subject Re: Fundamental Cocoon Philosophy Question
Date Mon, 13 Sep 2004 06:20:05 GMT
Julian

I'll jump in again.  Not sure of the history of Struts, but Cocoon
has been around (and evolving!) since at least 1999 - I think
it more than qualifies to be a "long lived" product.  As for
"stability";
well, the Web is in a constant state of flux - I think any product
that wants to maximise development opportunities *has* to 
evolve... which Cocoon has done, and done remarkably well.
[this from a satisfied *user*, not developer].  

As for adding in all the others aspects you mention; well, Lenya
has a workflow management system in release 1.2:
http://cocoon.apache.org/lenya/release.html
and as you said yourself Cocoon tends to "sprawl" - so adding in 
even more options is not necessarily going to help make it easier
to understand or use.  But I believe  that the blocks management 
system under development will go a  long way  to easing choice of 
subsets (or supersets) of current  (and future) technologies to help 
build the suite of technologies appropriate to *your* webapp needs.

The bottom line, for me anyway, is that Cocoon works because
of a great community that has always supported it.  If you choose
to get involved and not just watch from the sidelines, you will
find that out for yourself.

Derek

>>> cerebro70@yahoo.com 2004/09/11 06:21:16 PM >>>
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 


-- 
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


Mime
View raw message