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 Mon, 13 Sep 2004 16:17:50 GMT
Thanks yet again :)
See comments inline:

--- Ugo Cei <> wrote:
> > 1) Training developers
> I'll readily admit you have to have
> smarter-than-average developers to 
> deal with CForms, but if all your developers are
> dumber-than-average, 
> you have bigger problems to begin with ;-).

Agreed ;)

> > 2) Performance and Scalability
> We have some forms with hundreds of fields and I
> think you are going to 
> hit a usability threshold long before you hit any
> performance 
> threshold.

Thanks, although as many know, this is a major problem
with the current JSP paradigm that apps like Struts
have as well.

> > 3) Integration with third-party software packages
> > (other than SOAP or some other XMLRPC)
> > 4) Easy access to Java Library and my own Domain
> > to/from Cocoon (similar to #3)  Would all such
> access be in the Flow via JavaScript?
> I'd say most of the access to third-party libraries
> and domain code 
> would be in the Flow, but this does not mean that
> your Flow should 
> contain any business logic. You should implement a
> Service Layer 
> in Java and 
> use the Flowscript only as an Application Controller

This sounds interesting, but I will have to wait until
Martin's site is up and running again ;).  I would
particularly be interested in integrating a Workflow
Management System (WFMS) instead of using the Flow
paradigm (or perhaps a marriage of the two).  My
reasons include the safety of Javascript mappings
(particularly by the developer writing in JS) and the
maturity of many open source WFMS to handle a great
deal of decision making.  I also am interested in the
developments occuring with the Beehive project and
wonder how that may be detriment to Cocoon.

> > 5) Lock In
> Since the only known open standard here is XForms
> and there are no 
> widespread implementations of it, the risk of
> lock-in is present no 
> matter which solution you choose.

Agreed, however the current JSP/Servlet paradigm is
widely supported and would not nec. lock one into a
particular webapp framework. Then again, these do not
currently have robust forms yet.

> > 6) Front-end Widget Library
> The current CForms widget set is already pretty
> rich, and there's no 
> reason it can't grow.


> > 7) Forms production readiness
> We've had no problems related to CForms in
> production, yet. I guess the 
> greatest problem here is the (relative) instability
> of APIs. You have 
> to be prepared to do some work if you intend to
> follow CForms' 
> development.

Yes, this is why I may have to wait some time before
moving towards Cocoon.  The problem here is that once
CForms reaches a stable API, it will be too late for
my project.  However, I hope my endless ramblings here
are valued and help further the argument to implement


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!?
Shop for Back-to-School deals on Yahoo! Shopping.

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

View raw message