Here's an interesting question. When writing T4, did you know that T5 was going to be such a drastic rewrite? Probably not, or you would have just architected T4 the right way to avoid the rewrite. Correct? Well, then, who is to say that two years down the road whenever you get down to working on T6 that won't you decide the T5 architecture just won't work? You probably thought at the time of writing T4 that the architecture was the right way to go for the future and now it's "untenable w.r.t. to adding new features without breaking backwards compatibility."
Actually, T4 did come out better than I expected it to, which is very nice. But the entire time I was working on it, I was irritated by the many things I could not fix. I've been talking with people as far back as 2003 about the need for a pure POJO model with a transforming class loader. The different between the T3 -> T4 transition, and the T4 -> T5 transition is that instead of hacking around the limitations of the API (the cause of upgrade issues from one release to the next) I'm building such a minimal, adaptive API that upgrade issues won't exist in the future. I want to bring back the metaphor from my blog: In early 2000 I wound the spring on the Tapestry code base really tight. I found pretty much the right abstractions and patterns. I've made mistakes, overcome limitations, added powerful features. But all that time, the spring has been winding down. With T5 I want to wind the spring really, really tight again so that it'll last even longer.
I have (not that I necessarily think you were addressing me, but just in case) started to help make Tapestry more popular (Hibernate, Acegi, and AspectJ integration for starters) and I've contributed to Tapestry itself (autowiring), but a lot of my work will have to be completely rewritten for T5! Also, as a consultant, I have to recommend to my clients what technologies to use in their best interest. If Tapestry continues down the path that it's going, I could not endorse Tapestry as a viable technology solution for a large, on-going project. In other words, I wouldn't stick my neck out to suggest Tapestry given its track record.
-- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
