Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <s145c8de.058@cs-emo.csir.co.za>
Date: Mon, 13 Sep 2004 16:20:30 +0200
From: "Derek Hohls" <DHohls@csir.co.za>
To: <users@cocoon.apache.org>
Subject: Re: Fundamental Cocoon Philosophy Question
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Julian

OK; I haven't looked at Lenya in detail... as always,
if your requirements are more intensive, then you are
likely to have to pay for them somehow, in terms of
time or money!

As for modules, it sounds like you need to join the dev
list and contribute to their discussions...

Thanks
Derek

>>> cerebro70@yahoo.com 2004/09/13 03:33:58 PM >>>
Derek,

Thanks alot.  I agree with most of your points.  I
certainly do not contend Cocoon to be an unstable
project.  As far as the workflow is concerned, the
Lenya implementation is nice, but only as far as flows
that can be modeled as directed graphs.  I am looking
at more robust systems that include error handling,
splits, joins, EAI, etc.  These systems are mostly
Java based and integrating them with Cocoon may pose a
problem and influence my decision.  All in all, I was
simply concerned about the CForms component. Please
see my next post for those questions as they fit in
more with Thomas' post.  Oh, and regarding the blocks
system, I hope that it will be akin to Linux modules
that are separately downloaded and documented for
clarity sake.

Thanks,
Julian 

--- Derek Hohls <DHohls@csir.co.za> wrote:

> 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
> > 
> > 
> >
>
---------------------------------------------------------------------
> 
=== message truncated ===


=====
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 Address AutoComplete - You start. We finish.
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