Carsten Ziegeler <cziegeler <at> apache.org> writes: > > Sylvain Wallez wrote: > > Tell me your thoughts. Am I completely off-track, or do you also want to > > build this great new thing? > > > Hmm, I don't know - I think your ideas make mostly sense (we already > discussed some of them in the past), but for me these are technical > details (I don't say that they are not important). But I think, we need > a vision for 3.0 - what do we want to achieve? > > Now, most of the alternatives to Cocoon have one thing in common: they > are easy too learn and you can start quickly (and most of them have the > "start quick and fail later" problem but that's another story). Whereas > if you want to use Cocoon, you can't start right away. There is so much > to learn, so many different files you have to write/adjust. > > Why do managers love Struts or JSF? It's a "standard" but even more > important, they have tools. Fancy tools sell your product, that's the > bitter truth. And I have the feeling, that products, that don't have > tools but are "just cool", will not be used anymore (it's just a feeling).
Hello Carsten, Sylvain, I can tell you about my situation. We have developed a lot of applications based on Cocoon, first of all we have pointed our CMS on Cocoon Technology. In the last 2 years we started using Cocoon also for creating complex applications with CForms. Before, we just used Cocoon as container for Authentication, Content retrieval, aggregation, composition and all you can do with XSP. CForms seems to be the best for us - we are having a lot of Cocoon know how, CForms is fast to develop (in comparison with Struts) and everything could be customized. But we've forgotten something - and this was becomings my worst decision ever made. The customer has a dedicated hosting environment, BEA 8.1, Apache, Oracle and SUN JDK 1.4.2 all on Solaris / Sparc. Usual stuff, but Cocoon runs very slow in this environment, especially CForms and the newer JXTransformer. Tested on Intel Hardware or using Tomcat would solve the problem. Ive done a lot of performance optimizing but however, it never runs as fast as on JBoss. Some CForms Applications on BEA 6 with JDK 1.3 are running with an evil Cocoon SVN Checkout because this is the first version where the Rhino stuff is working but the last where Cocoon runs on JDK 1.3. Another point are reliable API's. It is worse enough, that no Template System is marked final and even CForms is still beta. It IS worse, that you wont be able to run your application on the next Cocoon Version. We still can not switch some applications from 2.1.6 to the actual version because of changes in Cocoon. CForms has Version 1, 2 and 3 - where discussed on the last GetTogether in Gent the Version 1 becomes the final Version. What do you expect from your users? Throw away all stuff done before? THats the point why stuff like JSF is much cooler in some cases then Cocoon. You can use many implementations (actutal SUN, Apache, Oracle) if one seems buggy, the API is RELIABLE and you can do updates of the implementation with small test efford. If you have some cool tools like NitroX, I think it is more pragmatic to use JSF with a faster result then using CFOrms for that. For me as developer I have learned that an unreliable API might be faster at the beginning, but will kicks your ass afterwards. I wont use any Cocoon API again without beeing sure the API is marked final and the used Cocoon Version has no bugs in that part so I can use it in that case if a newer Cocoon Version has changed the API. The first sentences from Silvain are absolutely correct - it is necessary to jump on the bandwagon and support the newest development mythologies like: POJOs, Ajax, IoC, DI and so on. Especially an excellent Ajax Support is very important, I think this trend will tend even more and more Swing / Client Applications to be ported to the web. The newest trends in J2EE are also important: POJOs, support of enterprise grade persistence (EJB3.0) instead of no-standard-implementations, switch the Avalon Container (sorry, dont know how far you guys are) to Spring container or another lightweight container platform, think about a standard interfacing to get reliable APIs, support of trails (https://trails.dev.java.net/) or a cocoon implementation, better interaction between other enterprise J2EE stuff like jetspeed or pluto and definitely a better test or use on weblogic, websphere and others. Just dont be angry about my receiveables, this are just my 2 cent after about 5 years Cocoon development. Sascha
