Thanks yet again :) See comments inline: --- Ugo Cei <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
