Il giorno 13/set/04, alle 16:06, Julian ha scritto:
Thanks for the input. I am glad this thread is still going b/c it proves to me the strength of this community. Anyway, the more I think about it, I enjoy Cocoon in many aspects, but have concerns about moving towards adopting CForms. So here are my concerns about going all in with Cocoon and CForms:
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 ;-).
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.
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>.
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.
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.
Ugo
-- Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
