Maybe it's not so crazy to start talking about future of T4 rather than app migration path from T4 to T5?
I'd be interested to dive deep into T4 internals by coding it further, having fun and learning with others. So when push comes to shove, and T5 is the next new big thing while T4 sits in the quiet, forgotten corner, I'd be interested to go onto a venture with someone to do something like Forestry 1.0 off of T4.... for those who would want to stay and keep developing T4-like apps. Alternatively, T4 could grow just fine under its current name without running out of version numbers (we could one day have T4.128.99 etc.), but then personal satisfaction for new maintainers isn't as great because from project standpoind you'd be developing this "older" version.. Few years from now T4 won't be "cool" enough because T5 and T6 will outshadow it. So if I started contributing to T4 codebase I'd rather do it under new name, which in the end is what open source is all about. It's about options. It's about freedom. It's about comfort of knowing that I CAN DO SOMETHING about it. It's about competition whose only merit is quality (and maybe taste to some degree). I thing Tapestry 4 is state of the art framework, and while I don't doubt that Howard is working on another beautiful framework, I'd love to see T4 (or whatever derivative of it) strong and healthy when my 2 year old goes to school.... On 8/1/06, James Carman <[EMAIL PROTECTED]> wrote:
Mark, you also have to consider a different type of user. For me, a component/framework extension developer (Tapernate, tapestry-acegi, etc.), I am not going to want to rewrite all of my cool stuff each time a new version of Tapestry comes out. No way will I maintain a version of my components for each version of Tapestry. What about Trails, which is helping Tapestry gain some attention by providing a cool RAD environment? If innovative folks get sick of having to rewrite their stuff all the time, then they'll just stop writing components for Tapestry altogether and that'll hurt the community. Also, what about tool developers? The cognition folks have a pretty cool Eclipse plugin that will probably have to be reworked for T5. Spindle also suffered the same growing pains. I don't want to put words into Geoff's mouth, but he seemed somewhat troubled by the fact that he had to totally rework Spindle for T4 from T3. Hugo Palma is creating a TapIDEA, an Intellij IDEA plugin. He'll also be impacted by this as his IDE extension will probably have to be completely reworked. I know that some folks aren't very impressed by tools and they don't think that tool support should be the reason that people choose a platform, but to some they are very important. -----Original Message----- From: Mark Stang [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 10:25 AM To: Tapestry users; Tapestry users Subject: RE: Tapestry 5 Discussions I don't think I agree. We switched to Tapestry from Struts because it gave us a component framework. Internally, we have three projects on Tapestry. One is 4.x and the other two are 3.x. For the 3.x projects we have looked at 4.x and while we would like to be on the latest and greatest, there isn't enough of a ROI to justify moving at this time. And since 5.x is in the "near" future we are waiting. However, we might not ever upgrade. What would cause us to upgrade? Everything works. And when we have had problems we post it to the group, which usually results in a fairly quick fix. Or if push comes to shove, we pay Howard. What more could you ask of a framework? And if you think about what brought us to Tapestry, it wasn't the upgrade path or support, it was the ability to develop components. >From everything I have read, we will still have "pages" and "components". Will we have to rewrite all of our components? I don't think we will have to do so, mainly because they are not that tied to the API. regards, Mark -----Original Message----- From: Danny Angus [mailto:[EMAIL PROTECTED] Sent: Tue 8/1/2006 7:51 AM To: Tapestry users Subject: Re: Tapestry 5 Discussions > Finally, let's take a sober look. Of all the production apps written > in T4, how many do you REALLY BELIEVE would be ported to T5? I'd say 1 > of a hundread, if that. On the other hand tapestry provides us the the ability to re-use components. If we want to write new applications in Tapestry5 do we throw away all our old components and lose their value? Or do we go to the expense of migrating them and writing new ones? For the people who are stuck requiring support for product which is likely to be ending its life the choice will be a stark one, not whether to upgrade to Tapestry 5, but what framework to migrate to. I would predict that most of the people who see their investment in components become increasingly worthless will have little loyalty left and will plump for something which is more likely to protect their investment, no matter what the technical limitations are. Look out for people offering a Tapestry4 to JSF migration path. d. **************************************************************************** *************************** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient please delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. **************************************************************************** **************************** --------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
