cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean Pierre LeJacq <>
Subject Re: Fundamental Cocoon Philosophy Question
Date Mon, 13 Sep 2004 15:09:15 GMT
On Mon, 13 Sep 2004, Ugo Cei wrote:

> Il giorno 13/set/04, alle 16:06, Julian ha scritto:
> > 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 ;-).

Relative to other technologies, CForms does not strike me as more
difficult to learn.  The major problem in this regard is the lack of
up to date documentation.

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

Completely agree.

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

This is my major worry about cforms.  CForms is so close to XForms
that I don't understand why this wasn't pursued (not a rant against
the developers of cforms - they obviously have their reasons).
There are several open source implementations - maybe not widepread
but I'm not sure you could say cforms is widespread either:

* Chiba (
* IBM XML Forms (
* Mozilla has announced a project to support xforms.


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

View raw message