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

--- Ugo Cei <ugo@apache.org> 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 
>
<http://www.martinfowler.com/eaaCatalog/serviceLayer.html>
> in Java and 
> use the Flowscript only as an Application Controller
> 
>
<http://www.martinfowler.com/eaaCatalog/applicationController.html>.

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.

Agreed.

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

Thanks,
Julian


=====
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!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool

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


Mime
View raw message