I know that we have exchanged emails on this topic before, but I just thought that I would chime in again with another advantage of Turbine. What I like about the way Turbine is set up is that it is more centered around making the life of the back-end developer easier, and it provides lots of nice containers and exits for you to customize. There are 3 in particular that I am a big fan of:
1) The Service framework (I am not on Avalon yet, but the old Services framework is cool too).
2) The PullTool abstraction.
3) The torque generated beans and bean peers.
It is great to have example pull tools and services available in the code, as it gives you some great pointers on what a properly modularized application should look like. Last time I worked with struts, they were less focused on this back end code layering concept and more concerned about managing session/request beans and JSP screen flows. Both are valuable, but I think that proper code layering on the back end provides more bang for the buck since it results in far more maintainable code. And best of all, the services framework allows you to substitute your own application specific extensions which is absolutely invaluable for high volume sites.
At tribe.net, we have had to re-implement the SecurityService ourselves, but this is not a big deal since the interface for that service is well defined, and once implemented the whole app (your code AND turbine code) will use your new service seamlessly. We have also jumped in and coded our own "ImageService" used for scaling and cropping images. This has been kind of a nightmare because no one here is intimately familiar with the magic juju inside the JAI package. As a result, we have gone thru a couple iterations of the ImageService, and it is easy for us to roll them all out to qa and/or production and switch between them in the TR.props file as necessary to test the results. Further, if we just give up and decide to farm out the ImageService, all we need to do is give someone with imaging expertise the interface file and let him go to town.
I guess the bottom line is that none of the ideas here are new, but the last thing you want to do is start from zero to implement them. Admittedly I have not tried all the frameworks out there, but if you are looking for a criteria for judging webapp frameworks for your project it may behoove you to include back end abstractions (service lifecycle management, MVC+1, etc.) among them.
-Brian
On Mar 28, 2004, at 6:14 PM, Peter Brown wrote:
Hello. Please excuse me for asking a question that has been asked a thousand
times before, but I have been unable to find a solid, coherent answer.
I would really like to know why Turbine is better or at least how it is
materially different than WebWorks2, Tapestry, Spring, JPublish or any other
mature application framework. I mean, anyone reading this message obviously
uses Turbine and I would love to hear your thoughts -- what do you like and
what do you dislike? Why should I use Turbine instead of WebWorks2 or
Tapestry? Where there any ways in which Turbine inhibited the development of
your projects?
Additionally, I am curious as to the current state and future direction of
Turbine. For example, I have noticed that clicking on the Turbine 2.4 link
from the Turbine home page produces a 404
(http://jakarta.apache.org/turbine-2.4/index.html). Yet I have read that a
whole series of improvements, such as better Avalon component integration or
a fully removed Torque, will be available only in Turbine 2.4. Is this
project still moving forward? Is it a different codebase than 2.3 as I
understand Turbine 3 was supposed to be, or is it simply an updated 2.3?
Thanks Very Much,
Peter T. Brown
--------------------------------------------------------------------- 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]
