I mostly support what Eric writes. Although our situation is different, we are just in the throes of deciding whether to use Turbine, and many of the same reasons lean in its favor. I would add to all that Eric wrote one nice feature: the Turbine developers have done their design with close attention to maintaining interface/implementation splits. There are many things about the standard "as-downloaded" Turbine web application that we need to change because of business requirements, sometimes with very non-trivial changes. However, in most cases all we need to do is subclass one of the implementations; at worst, we just need to rewrite an implementation but maintain the interface. Nice. This is a far cry from a framework where all accesses are done directly to a class implementation.
That having been said, I cannot say that I agree with the push (so to speak) toward using the Pull model. My experience has shown that, at least in many situations, a pure Pull model is harder to work with. I hasten to say that I also don't advocate a pure Push model as demonstrated by the sample Turbine app. Rather an "in-between" model where an intermediate registry maps between a "page" and the associated classes and templates. Our user interface designers don't see java code: they see the registry and the templates, that's all. Yes, sometimes java developers have to be involved in making changes, but for some things they ought to be involved. Changes to things like page flow, content, and layout can still be made without Java developer help, by modifications to registries. Thus, the user interface people own the templates, the java coders own the java code, and the registries are sort of an in-between, jointly owned by both. A large project using this model I worked on (6 user interface people, 15 programmers)worked fine; in fact the problems we had were when people put code (pull model, I note) into the JSPs. I'm not saying the Pull model never works, just that I certainly hope that the Push model doesn't become passe or otherwise non-supported in future versions (3.x?) of Turbine. In fact, the freedom to do Push or Pull is exactly the kind of reason I advocate Turbine; I seems to me (a relatively new Turbine aficionado) a Pull mandate would be very non-Turbine-like. Thanks for listening. <>< gary -----Original Message----- From: Eric Dobbs [mailto:[EMAIL PROTECTED]] Sent: Friday, February 01, 2002 2:54 PM To: Turbine Users List Subject: Re: Question: Turbine 3 Release schedule/Features On Thursday, January 31, 2002, at 09:02 AM, Brian McKendrick wrote: > I am in the process of doing diligence on Turbine as a platform for my > company's thin client applications. I have not found much information > on Turbine 3's release schedule or many of it's real improvements. I > will find it difficult to recommend porting our apps once to Turbine > 2.x, and then again to Turbine 3. There isn't a release schedule for Turbine 3. Your question suggests that you may be new to opensource development. If I've guessed that incorrectly, then some of this will be stuff you should already know. Let me offer our business rationale for choosing Turbine. We chose Turbine just over a year ago, while version 2.1 was being polished for release. At the time we began, we were in the midst of a typical "build vs. buy" debate. As an opensource project, Turbine falls somewhere between those options. You don't have to buy it, but you do have to invest some development time to really make it work for you. We had already paid to build a proprietary framework, but budgets were cut before it was completed. We couldn't afford to finish it (and to maintain it, for that matter) with our small development team. And with our tight budget we couldn't afford the "buy" option. Turbine was a perfect fit in our situation. It was radically more mature than our own framework offering features we had not even discovered we needed. In choosing any system you face the risk of having to update your application as that system evolves over time. This is not something unique to turbine, or even to opensource. Evolution of the framework is a risk. In the case of a commercial vendor, you have some assurance that they will make the migration to the new version graceful. But there are many cases where businesses have been burned by that assumption. There are some aspects of Turbine that mitigate these risks. Apache and Jakarta have excellent reputations for production quality development and has good brand recognition. Turbine inherits some of that intangible benefit since it's a Jakarta project. There is a very active community of developers who have demonstrated a long-term commitment to the project. Most of them also depend on having Turbine work for their own production systems. By their own self interest there will be a migration path from v2 to v3 once v3 is sufficiently stable to justify migrating the production applications. Because the development is open, we can influence the next release by our contributions, both in code and conversation. We have far more direct involvement about what will be in the next version of Turbine than we would with a commercial vendor. This doesn't come for free -- your developers have to spend the time to keep up with the Turbine development. But in our case we've seen an exceptional return on that investment. You happen to be coming to Turbine at an especially good time. Version 2.2 is coming very soon (from other threads on this list "soon" could be within weeks. There's no official schedule, so be aware of that risk.) This will be an important step in the migration to T3. One of the differences between T2 and T3 is that some components have been decoupled in T3 (specifically Torque and Fulcrum). Turbine 2.2 will also use those decoupled components. It is possible that by the time you begin your development you will have less "migration" to worry about between T2.x and T3. Lastly, if you do choose Turbine, you should learn all you can about the Pull model, because that is the preferred method of building turbine apps and will definitely be supported in T3 (thereby making the migration easier). Hope that helps, but you have to decide for yourself if the risks of using Turbine are better or worse than your alternatives. -Eric -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
