Hi Fernando, Frankly, it's not directly a technical question. Howard is moving on from Tapestry 4, going in a less-xml-more-pojos-with-annotations direction. I think what you have to base your decision on a investment strategy, not on technical merits.
Our shop invested heavily in Tapestry 3, and then we did the steep learning curve before a good book on Tapestry 4 was available (Kent's), using Howard's book as a starting point. We decided to run with Tapestry 4 with the first beta for an in-house application and developed against CVS-checkouts along the way. That was a lot of work, keeping up with the changes, at times maintaining our own branch. JSF/JSP will go the same way that the J2EE 1.3/1.4 stack did: a number of frameworks will emerge that will help along with the problems that developers will experience. That's precisely how we gained Dependency Injection and coarse-grained ORM in JEE 5. Tapestry 4 rode on that wave, so currently it's the lean alternative with all the upsides and no apparent downside (has anyone integrated Hivemind/Tapestry with JEE-style @Resource-Injection??) BUT in 3 years time, you will have to move on, to support new technologies, new development paradigms and perhaps to support a big new version(tm) of the software you're going to develop now. And, frankly, I fear that Tapestry might be a bad investment decision at that point if you don't keep up with Tapestry 5 development, as (even less than with Tapestry 3) there's no migration path. We're currently having one Tapestry 3 application that we'll need to extend soon. Unfortunately, the customer will not pay for an upgrade to Tapestry 4 after we calculated the time that it would take to do so. So we're stuck with a deteriorating codebase, with currently no way forward, that will make it harder and harder over time to add new features. The main problem I have now when talking to management is that I cannot guarantee that we don't have the same problem 2 years from now, when Tapestry 5 matures. This requires us to have developers on staff that are able to work with a Tapestry 3 application that will need a new feature once in a while but not often enough to justify a full upgrade. So the questions I'd ask are: * how many developers do you have to train and how big is the chance that they'll work with JSF in the future in unrelated projects? * does the customer allow you to incorporate new technologies as they emerge or do they need a very stable codebase? * how many applications will you develop with this technology? * how long do you expect to support the software and how much is it going to grow in this time? * is there a chance to have a, at worst, multiple-months upgrade period to replace first parts of the application, or the application as a whole with something new? or is it more of a "fire-and-forget"-application that will most likely not see big investments in the future? Please understand me correctly! I don't want to spread any FUD here... Tapestry is a GREAT framework, it let's you get things done very quickly in a very clean way and JSF is not even NEAR the productivity you gain from Tapestry, but you need to factor in future costs or else you might encounter a big surprise in 2 years time. The first part would be to create a budget for keeping up with Tapestry 5 development. For example, just get Howard on a plane twice over the next 2 years, or something like that, so he can keep you up to date. But to sum up my email: in my experience future cost and portfolio management should drive your decision, not technical merits. I hope that helps a bit Jonas PS: and just to say it: If you just need to develop a blogging application, Ruby on Rails or Django might be better... you can do that in 20 minutes there as opposed to 30 minutes in Tapestry with Hibernate or EJB 3.0 ;-), so a "small" application might not get you the statistical data you want. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
