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 > <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>. 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 (http://chiba.sourceforge.net/) * IBM XML Forms (http://www.alphaworks.ibm.com/tech/xmlforms) * Mozilla has announced a project to support xforms. -- JP --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
