I keep feeling like a second class citizen here with my and Andys tapestry 4.1 (and 4.2/etc future releases) development.. :/
Just because Howard is working on the future of tapestry it doesn't mean that Tapestry4 is dead by default...I have a ~lot~ of time invested in 4 and don't plan on seeing it go to waste.. So..To be clear..I do nothing but dojo/tapestry development for a living. Seeing it hurt/deterioted hurts me as well. I'm also pretty much the "main" dev(besides Andy, who is becoming more and more active lately) on 4.1 and have lots of exciting plans for it. My 2 cents to make sure the people actively developing Tapestry have their say as well. (i should say I am a user of course as well ;) ) On 9/6/06, Jonas Maurus <[EMAIL PROTECTED]> wrote:
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]
-- Jesse Kuhnert Tapestry/Dojo/(and a dash of TestNG), team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
