Struts seems to be the most widely used and documented one out there. Have you guys looked at Maverick? http://mav.sourceforge.net I like it a lot, but it seems way too undocumented..
I am currently weighing the use of Turbine, Maverick, or Cocoon as the webapp framework for a doc mgmt system we are building.. -----Original Message----- From: Akshay Kapur [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 7:48 PM To: Turbine Users List Subject: Re: Why Use Turbine? >>My application, which uses lots of Velocity templates rather than JSPs, is not at all portable to other servlet containers. I don't understand what that means. Can anyone explain? The one thing that I am concerned about is that Turbine has little documentation. Whereas, Struts even has a book by Oreilly and is becoming a de-facto which makes me paranoid - Why is Struts more popular as compared to Turbine? Is Turbine getting overtaken by the Struts hype(or is this a wrong perception)? At 05:18 PM 3/6/2003 -0700, you wrote: >I've designed a fairly complex app in Turbine just to get to know it. >MySQL connectivity, lots of forms and actions, sort of a classmates.com >clone for a small private school I went to. > >It works fine in the TDK, although it took me about 5X longer to implement >it than I thought it would. Some of that was due to my own poor ability to >project plan, but a lot was due to the unexpected difficulty of >troubleshooting. The documentation is very incomplete - understandably, >since this is a volunteer project. When things didn't work the way I >expected it took hours and days to tease the solution out of the mail list >archives and the unstructured documentation. > >I think I've just stumbled across another major reason NOT to use Turbine. >My application, which uses lots of Velocity templates rather than JSPs, is >not at all portable to other servlet containers. Naively, I installed >Tomcat without Turbine on my "production" machine (an old PC in my home >but it hosts my Apache HTTP web server) thinking I could deploy the app >there. Imagine my "well, duh!" when I realized that Velocity is needed to >parse and translate my templates. > >It occurs to me that an app developed in Turbine using Velocity templates >is not portable to any other application server. If I had used JSPs >instead, I could port it to any app server that has a compliant servlet >container. Considering that very few ISPs support full blown Apache HTTP >server - Turbine - Tomcat - Velocity platforms, this seems like a pretty >big limitation. > >Yes, I can develop JSP or stricly servlet applications in Turbine, but >without Velocity what's the point? Why not just use Tomcat alone? The >documentation is much better, the infrastructure is simpler, and the >connection to Apache HTTP web server is fairly straightforward. > >One argument for using Turbine might be that, for large-ish scale >development where you have graphic designers doing the page layout, the >Velocity syntax is a hell of a lot easier for them to understand than Java >syntax in JSPs. I don't consider this much on an argument. Writing the >Velocity code presumes a good understanding of the context objects it >references, so I think the Java programmers have to do a lot of this anyway. > >Another might be the rich facility Turbine offers for navigations and >layouts. Can't this be handled pretty easily with a similar directory >structure and conditional JSP include directives? > >I'm probably missing important points, but I think this is a good thread >to start. People just getting started with Turbine need to know what it >CAN'T do as well as what it can do. > >-- >George Allaman >Denver, Colorado >303 466 2114 > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
