RE: Tapestry 5 Discussions
Isn't there some sort of ExpressionEvaluator service in HiveMind now? Is that where you'd plug in another expression language? -Original Message- From: Ben Eng [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 08, 2006 3:33 PM To: Tapestry users Subject: Re: Tapestry 5 Discussions Howard, I was only offering up an idea in response to your comment about OGNL not providing an adequate solution for Tapestry 5. You seemed to be searching for an expression language that could translate into both server-side and client-side implementations. Ben On Tue, Aug 08, 2006 at 09:07:13AM -0700, Howard Lewis Ship wrote: > Everything will be pluggable, just like in Tapestry 4. Why not create this > for Tapesty 4 today? > > On 8/8/06, Ben Eng <[EMAIL PROTECTED]> wrote: > > > >Howard, > > > >How about adopting XPath expressions as an alternative to OGNL? Apache > >Commons JXPath could provide a server-side implementation, while > >something like Google AJAXSLT can implement XPath (as a part of XSLT) > >in JavaScript on the client side. See > >http://goog-ajaxslt.sourceforge.net/ > > > >Ben > > > >On Thu, Aug 03, 2006 at 11:47:46AM -0700, Howard Lewis Ship wrote: > >> As per my early blog post ( > >> > >http://howardlewisship.com/blog/2006/03/from-fanciful-ideas-category.html), > >> I would like to see object editting be dirt simple in Tapestry 5, using > >> built in components. I'll be discussing some of this with Chris Nelson > >this > >> weekend. > >> > >> I would like to see Trails5 be an Apache project next to Tapestry5. > >> > >> One thing I hope to do is bridge the gap between Tapestry components and > >the > >> entity objects that contain the properties being updated. To wit, a > >> component such as TextField should be able to see the setter method that > >it > >> will ultimately invoke, and be able to convert annotations (both defined > >by > >> Tapestry and defined by external sources such as EJB3 and Hibernate) > >into > >> server-side and client-side validation logic. > >> > >> The upside is automatic coordination of validation at multiple layers. > >> > >> The downside is that we may leave OGNL behind in the process, since its > >APIs > >> don't support anything like this. I'll be discussing that with Drew > >> Davidson next week. Of course, synthetic properties and instant class > >> reloading will reduce the necessity of OGNL. > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
Howard, I was only offering up an idea in response to your comment about OGNL not providing an adequate solution for Tapestry 5. You seemed to be searching for an expression language that could translate into both server-side and client-side implementations. Ben On Tue, Aug 08, 2006 at 09:07:13AM -0700, Howard Lewis Ship wrote: > Everything will be pluggable, just like in Tapestry 4. Why not create this > for Tapesty 4 today? > > On 8/8/06, Ben Eng <[EMAIL PROTECTED]> wrote: > > > >Howard, > > > >How about adopting XPath expressions as an alternative to OGNL? Apache > >Commons JXPath could provide a server-side implementation, while > >something like Google AJAXSLT can implement XPath (as a part of XSLT) > >in JavaScript on the client side. See > >http://goog-ajaxslt.sourceforge.net/ > > > >Ben > > > >On Thu, Aug 03, 2006 at 11:47:46AM -0700, Howard Lewis Ship wrote: > >> As per my early blog post ( > >> > >http://howardlewisship.com/blog/2006/03/from-fanciful-ideas-category.html), > >> I would like to see object editting be dirt simple in Tapestry 5, using > >> built in components. I'll be discussing some of this with Chris Nelson > >this > >> weekend. > >> > >> I would like to see Trails5 be an Apache project next to Tapestry5. > >> > >> One thing I hope to do is bridge the gap between Tapestry components and > >the > >> entity objects that contain the properties being updated. To wit, a > >> component such as TextField should be able to see the setter method that > >it > >> will ultimately invoke, and be able to convert annotations (both defined > >by > >> Tapestry and defined by external sources such as EJB3 and Hibernate) > >into > >> server-side and client-side validation logic. > >> > >> The upside is automatic coordination of validation at multiple layers. > >> > >> The downside is that we may leave OGNL behind in the process, since its > >APIs > >> don't support anything like this. I'll be discussing that with Drew > >> Davidson next week. Of course, synthetic properties and instant class > >> reloading will reduce the necessity of OGNL. > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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]
Re: Tapestry 5 Discussions
Everything will be pluggable, just like in Tapestry 4. Why not create this for Tapesty 4 today? On 8/8/06, Ben Eng <[EMAIL PROTECTED]> wrote: Howard, How about adopting XPath expressions as an alternative to OGNL? Apache Commons JXPath could provide a server-side implementation, while something like Google AJAXSLT can implement XPath (as a part of XSLT) in JavaScript on the client side. See http://goog-ajaxslt.sourceforge.net/ Ben On Thu, Aug 03, 2006 at 11:47:46AM -0700, Howard Lewis Ship wrote: > As per my early blog post ( > http://howardlewisship.com/blog/2006/03/from-fanciful-ideas-category.html), > I would like to see object editting be dirt simple in Tapestry 5, using > built in components. I'll be discussing some of this with Chris Nelson this > weekend. > > I would like to see Trails5 be an Apache project next to Tapestry5. > > One thing I hope to do is bridge the gap between Tapestry components and the > entity objects that contain the properties being updated. To wit, a > component such as TextField should be able to see the setter method that it > will ultimately invoke, and be able to convert annotations (both defined by > Tapestry and defined by external sources such as EJB3 and Hibernate) into > server-side and client-side validation logic. > > The upside is automatic coordination of validation at multiple layers. > > The downside is that we may leave OGNL behind in the process, since its APIs > don't support anything like this. I'll be discussing that with Drew > Davidson next week. Of course, synthetic properties and instant class > reloading will reduce the necessity of OGNL. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
Re: Tapestry 5 Discussions
Howard, How about adopting XPath expressions as an alternative to OGNL? Apache Commons JXPath could provide a server-side implementation, while something like Google AJAXSLT can implement XPath (as a part of XSLT) in JavaScript on the client side. See http://goog-ajaxslt.sourceforge.net/ Ben On Thu, Aug 03, 2006 at 11:47:46AM -0700, Howard Lewis Ship wrote: > As per my early blog post ( > http://howardlewisship.com/blog/2006/03/from-fanciful-ideas-category.html ), > I would like to see object editting be dirt simple in Tapestry 5, using > built in components. I'll be discussing some of this with Chris Nelson this > weekend. > > I would like to see Trails5 be an Apache project next to Tapestry5. > > One thing I hope to do is bridge the gap between Tapestry components and the > entity objects that contain the properties being updated. To wit, a > component such as TextField should be able to see the setter method that it > will ultimately invoke, and be able to convert annotations (both defined by > Tapestry and defined by external sources such as EJB3 and Hibernate) into > server-side and client-side validation logic. > > The upside is automatic coordination of validation at multiple layers. > > The downside is that we may leave OGNL behind in the process, since its APIs > don't support anything like this. I'll be discussing that with Drew > Davidson next week. Of course, synthetic properties and instant class > reloading will reduce the necessity of OGNL. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
Sorry for adding further flame on this discussun (not my intention) but it's very sad to see all this discussions about Tapestry 5 and I need to say a few words. I was a big fan of Tap and was the only one in my company who stood up for it. We used it for a few big projects for major Swiss banks. Projects were successful, but written in Tap3. Switching to Tap4 was a lot of pain for me. Transition is not so huge, but still... not all developers in my company are as enthusiastic as me... I had to persued them to think a bit different, to start using HiveMind and to explain to managers why is it so benefitial and why is it worth postponing the deadline for a while. Then this story about Tap5 came... HiveMind is out, IoC is in, no backward compatibility... As being software architect in the company and a team leader, I would sound irresponsible and childish if I would have to suggest a new transition all over again. I don't think I have so much credit left with business managers to justify that. I went for another solution. HTML templates written in FreeMarker with DWR framework that communicate with server side Java methods over Ajax is actually all we needed. For some components we used Dojo + Script.aculo.us, and server side beans are managed by Spring. We created a set of very nice components which we could combine for any kind of Web application. Two new projects of the same size as previous were successfully finished with this combination. Very clean code/html separation, reusable components, almost zero learning curve, productivity much higher... Sorry Howard, but after this I have abandoned Tap for good. I just don't see where it fits anymore and what is it trying to simplify for me Howard Lewis Ship wrote: As per my early blog post ( http://howardlewisship.com/blog/2006/03/from-fanciful-ideas-category.html ), I would like to see object editting be dirt simple in Tapestry 5, using built in components. I'll be discussing some of this with Chris Nelson this weekend. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
As per my early blog post ( http://howardlewisship.com/blog/2006/03/from-fanciful-ideas-category.html ), I would like to see object editting be dirt simple in Tapestry 5, using built in components. I'll be discussing some of this with Chris Nelson this weekend. I would like to see Trails5 be an Apache project next to Tapestry5. One thing I hope to do is bridge the gap between Tapestry components and the entity objects that contain the properties being updated. To wit, a component such as TextField should be able to see the setter method that it will ultimately invoke, and be able to convert annotations (both defined by Tapestry and defined by external sources such as EJB3 and Hibernate) into server-side and client-side validation logic. The upside is automatic coordination of validation at multiple layers. The downside is that we may leave OGNL behind in the process, since its APIs don't support anything like this. I'll be discussing that with Drew Davidson next week. Of course, synthetic properties and instant class reloading will reduce the necessity of OGNL. On 8/3/06, hv @ Fashion Content <[EMAIL PROTECTED]> wrote: > My goal is not to beat JSF, but to give Java developers a compelling > reason to stay on Java and not jump over to Ruby on Rails. That's a > tall order. I think that's a very strong motivation indeed. I'm glad you are thinking along those lines. Having played around with ASP.NET/C# recently I can see some attractiveness in that direction as well. Java really needs a much better framework for modern web apps than what we have, and T5 sounds like it will be a strong candidate. What are your thoughts on component data models. Are they going to evolve in T5 or is that up to Trails to do that ? Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
Re: Tapestry 5 Discussions
> My goal is not to beat JSF, but to give Java developers a compelling > reason to stay on Java and not jump over to Ruby on Rails. That's a > tall order. I think that's a very strong motivation indeed. I'm glad you are thinking along those lines. Having played around with ASP.NET/C# recently I can see some attractiveness in that direction as well. Java really needs a much better framework for modern web apps than what we have, and T5 sounds like it will be a strong candidate. What are your thoughts on component data models. Are they going to evolve in T5 or is that up to Trails to do that ? Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Re: Tapestry 5 Discussions
"Epstein, Ezra" <[EMAIL PROTECTED]> wrote on 01/08/2006 21:31:27: > Rather I was questioning how the decision about IoC adoption is > being made. At the time HiveMind got started the IoC container > space was pretty open and empty. I don't really think thats true at all, but Hivemind did have some advantages over the competition, mostly the fact that it had been designed by Howard as the IoC provider for Tapestry. > Of course Spring lacks features needed. Understood. Could Spring > be extended? I find that quite hard to believe, more likely those who are saying so don't have the experience of Spring required. Of course it might still be *difficult* to use Spring for Tapestry IoC, but that is a different issue, and as Spring is an OSS roject too there is little doubt that the Tapestry team could engage with the Spring guys to work out whats needed. > The trouble we all have -- it is certainly not unique to a creator > of software or this software -- so I'm speaking of my own > experience, is that I (and most folks I know) tend to get a bit > skewed in favor of things that are our "babies" so to speak. And > there's nothing wrong with that. But we need to recognize it when > we're trying to make a decision and then correct for it. +1. 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]
Re: Tapestry 5 Discussions
"Howard Lewis Ship" <[EMAIL PROTECTED]> wrote on 01/08/2006 17:34:47: I tend to agree with most of what you said. > The central issue is backwards compatibility. As the upgrade from 2 to > 3 to 4 has shown, adding new features to Tapestry often breaks > existing code. This is a reaction to the relationship between the > framework code, and the application code. The fact that application > classes extend framework classes means that virtually any change to > the framework classes exposes client code to incompatibilities. Yep, this is the key issue at stake, and in fact it also appears to manifest itself as unnecessary inflexibility and constraints on component development. Changing this is a clear benefit, no doubt about it. > I've forced people to choke down the poison pill in little stages, > from 2 to 3 to 4. I don't expect that to happen once 5 is out ... the > annotation-based APIs are wonderfully flexible and adaptive even when > the framework is changed. That is a welcome positive message. > My goal is not to beat JSF, but to give Java developers a compelling > reason to stay on Java and not jump over to Ruby on Rails. That's a > tall order. With all due respect the way you need to go about that is to capitalise on the loyalty of your existing users, support us in achieveing our sucesses with Tapestry and we'll promote your project, no question. I don't underestimate the effort required to provide a migration path, but neither should you underestimate the value of retaining your existing users. The two features of Tapestry which really sell it into a commercial enterprise are 1) reuse and 2) the excellent separation of concerns between HTML & functional programing. To have no upgrade path at all would be to remove 1 as a benefit for existing users. I'm pretty sure that people will step up and contribute to an effort to provide backwards compatibility and upgrade tools, there is clear self-interest there to motivate us, but only if we think you guys really buy into the nesessity of it, and can convince us that it will be a once-and-final big-bang. Otherwise JSF, ruby on rails, even Oracle ADF, or any damn thing out there, will be seen as no more of risk or an effort to move to than sticking with Tapestry as a strategic choice will be. We have made the strategic decision to use Tapestry please don't make me change it. Those of us who have a broader view of product selection than technical excellence alone, we have to take into account the cost of ownership, will be hard pressed to continue to justify our decision if we don't have some kind of assurance that this really is a final one-off cost. Your earlier statement goes some way towards that I'm glad to say. Brian McCallister gave a great presentation on "managing open source" at ApacheconEU 05, (slide are here [1]) one of the key messages he made, and which is reinforced by the principles of schemes like CMMi and ISO9000 is that evaluation of OSS by commercial users must take into account the predictability & stability of the project and the ease of engagement with the community. Clearly documented roadmaps and statements of intent, and support for user-led initiatives are whats needed now if you want to pass those tests. Get behind and promote an effort to provide a migration path, no one expects you to do all of the work just to promote it, set out and end-of-life timeline for Tap3 and 4, document your decisions and I'm sure we'll stay with the programme. d. [1] http://www.chariotsolutions.com/slides/apachecon_managing_oss.pdf *** 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]
Re: Re: Tapestry 5 Discussions
On 8/1/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote: I think there's a mis-communication. I do not at all feel HiveMind is "just an ego trip." Far from it. Rather I was questioning how the decision about IoC adoption is being made. At the time HiveMind got started the IoC container space was pretty open and empty. Not so anymore. Of course Spring lacks features needed. Understood. Could Spring be extended? The trouble we all have -- it is certainly not unique to a creator of software or this software -- so I'm speaking of my own experience, is that I (and most folks I know) tend to get a bit skewed in favor of things that are our "babies" so to speak. And there's nothing wrong with that. But we need to recognize it when we're trying to make a decision and then correct for it. If HM is the best choice (not just technically, but also in terms of adoption) then great, but what's the process of deciding? Is it worth exploring Spring enhancements? That was the point. I believe each of these containers has its place. Spring is more "business" oriented, and has a great API for transactions and working with DAO. For anything that has to do with business logic, spring is fantastic. But it is far from lightweight and currently it would require way more xml + code to do what hivemind is doing. Hivemind was the main glue in tapestry 4 and allows to customize any part of tapestry and wire your own stuff. But many tapestry 3 users have been complaining about hivemind, it adds a fair learning curve for tapestry. Howard's IoC solution seems to me the most appropriate... It is very lightweight and dedicated. No need to bother with an xml configuration + java stuff. Everything will be in the code and the internal mecanims will be dedicated for tapestry. This should lower the learning curve quite a bit. Once the IoC will be finished I heard about plans for using the same model for hivemind... And at that point it would be really nice if somekind of spring integration could happen too. I'd like to use tapestry/hivemind and spring more seamlessly. Thanks -- Henri Dupre Actualis Center
RE: Re: Tapestry 5 Discussions
I think there's a mis-communication. I do not at all feel HiveMind is "just an ego trip." Far from it. Rather I was questioning how the decision about IoC adoption is being made. At the time HiveMind got started the IoC container space was pretty open and empty. Not so anymore. Of course Spring lacks features needed. Understood. Could Spring be extended? The trouble we all have -- it is certainly not unique to a creator of software or this software -- so I'm speaking of my own experience, is that I (and most folks I know) tend to get a bit skewed in favor of things that are our "babies" so to speak. And there's nothing wrong with that. But we need to recognize it when we're trying to make a decision and then correct for it. If HM is the best choice (not just technically, but also in terms of adoption) then great, but what's the process of deciding? Is it worth exploring Spring enhancements? That was the point. Thanks, Ezra Epstein -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of hv @ Fashion Content Sent: Monday, July 31, 2006 4:27 AM To: users@tapestry.apache.org Subject: Re: Tapestry 5 Discussions Trashing HiveMind is sort of uninformed(not trying to sling mud). As previously pointed out you can't really do contributions in Spring. And that was one of the key T3 features it was supposed to replace. While I'm not terribly happy about the multitude of concepts involved in writing a non-trivial Tap4 app, I bet it would have been much worse if it had been built on Spring. Being a bit blunt: If you think HiveMind is just an ego trip why dont you write a version of ApplicationServlet that uses Spring instead. If the two are equal it shouldn't be much of a challenge to swap HiveMind out. Henrik - 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]
Re: Tapestry 5 Discussions
I don't agree. Why can't T5 "host" T4 or T3 components? -- Ing. Leonardo Quijano Vincenzi DTQ Software Web Application Design and Programming http://www.dtqsoftware.com James Carman escribió: Well put! Component reuse is a big reason to use Tapestry. We already have to have two different flavors of components on the Tassel site; one for T3 and one for T4. Are those folks going to have to completely rewrite their components for T5 and put them back out there, thus creating 3 different versions to maintain? -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 9: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]
Re: Tapestry 5 Discussions
It's refreshing to see a number of people out there who "get" where Tapestry is headed. There is always a tension between compatibility and the drive for new features. Tapestry's baggage: the base classes that begat abstract classes; the conflict between page names and class names, the plethora of lookup paths for various artifacts ... all of these things are choking Tapestry. Looking forward, where full page updates are the exception, and Ajax-oriented partial page renders are the norm, Tapestry 4 will not be able to keep up. Jesse has been proving himself as the master of this stuff, but there are just some issues buried in the DNA of Tapestry 4 that extend all the way back to the Tapestry prototype in 2000. Perhaps I should have kept quiet until I had more of T5 to show. I think everyone is going to agree that the new feature set, the new style of development, the simplicity and the power, are going to be quite compelling. The central issue is backwards compatibility. As the upgrade from 2 to 3 to 4 has shown, adding new features to Tapestry often breaks existing code. This is a reaction to the relationship between the framework code, and the application code. The fact that application classes extend framework classes means that virtually any change to the framework classes exposes client code to incompatibilities. Further, the fact that so much logic passes through user code causes its own set of problems when we want to add in more radical new features (such as true WYSIWYG preview). I've forced people to choke down the poison pill in little stages, from 2 to 3 to 4. I don't expect that to happen once 5 is out ... the annotation-based APIs are wonderfully flexible and adaptive even when the framework is changed. My goal is not to beat JSF, but to give Java developers a compelling reason to stay on Java and not jump over to Ruby on Rails. That's a tall order. On 8/1/06, Mark Stang <[EMAIL PROTECTED]> wrote: James, One of the reasons we haven't switched is because Geoff's Spindle wasn't there. So, I agree, that tools are important. My point was, that most Tapestry Users won't migrate over to JSF just because we have to upgrade. I agree that Geoff has had an extraordinary bad time of providing an upgrade to Spindle for 4.x. However, I read his e-mails and the problems that he is encountering are, in a large part, due to the framework gone wild of 4.x. The main reason that 5.x exists is because 4.x is such a wild child. It has gotten out of control. The reason that 4.x exists AT ALL is because, as Howard was writing the next version of Tapestry, people were complaining that there wasn't any upgrade path. That the differences between 3.x and 4.x of old were so different that everbody was complaining. Everyone wanted 4.x as an intermediate version. It is there for those who couldn't use 3.x and didn't want to wait for 4.x. So, in reality, 4.x is just a stop-gap, not to denigrate all the work Jesse, et.al. have contributed (he is a wild man). The "next generation" of Tapestry is not 4.x or 3.x, it is 5.x. Should Geoff have done 4.x? I think he did it because we pushed him into it because we weren't willing to wait for 5.x. Bottom-line, 5.x is the future, 3.x and 4.x are prototypes and support will decline for both of them as 5.x becomes the standard. With that said, if Howard has some brilliant idea and abandons 5.x, all hell will break loose. But from his e-mails, the plan is to maintain and enhance 5.x for the future. All roads lead to 5.x regards, Mark -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Tue 8/1/2006 9:06 AM To: 'Tapestry users' Subject: RE: Tapestry 5 Discussions 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 t
RE: Tapestry 5 Discussions
James, One of the reasons we haven't switched is because Geoff's Spindle wasn't there. So, I agree, that tools are important. My point was, that most Tapestry Users won't migrate over to JSF just because we have to upgrade. I agree that Geoff has had an extraordinary bad time of providing an upgrade to Spindle for 4.x. However, I read his e-mails and the problems that he is encountering are, in a large part, due to the framework gone wild of 4.x. The main reason that 5.x exists is because 4.x is such a wild child. It has gotten out of control. The reason that 4.x exists AT ALL is because, as Howard was writing the next version of Tapestry, people were complaining that there wasn't any upgrade path. That the differences between 3.x and 4.x of old were so different that everbody was complaining. Everyone wanted 4.x as an intermediate version. It is there for those who couldn't use 3.x and didn't want to wait for 4.x. So, in reality, 4.x is just a stop-gap, not to denigrate all the work Jesse, et.al. have contributed (he is a wild man). The "next generation" of Tapestry is not 4.x or 3.x, it is 5.x. Should Geoff have done 4.x? I think he did it because we pushed him into it because we weren't willing to wait for 5.x. Bottom-line, 5.x is the future, 3.x and 4.x are prototypes and support will decline for both of them as 5.x becomes the standard. With that said, if Howard has some brilliant idea and abandons 5.x, all hell will break loose. But from his e-mails, the plan is to maintain and enhance 5.x for the future. All roads lead to 5.x regards, Mark -Original Message- From: James Carman [mailto:[EMAIL PROTECTED] Sent: Tue 8/1/2006 9:06 AM To: 'Tapestry users' Subject: RE: Tapestry 5 Discussions 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 t
Re: Tapestry 5 Discussions
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
RE: Tapestry 5 Discussions
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. --
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]
RE: Tapestry 5 Discussions
Well put! Component reuse is a big reason to use Tapestry. We already have to have two different flavors of components on the Tassel site; one for T3 and one for T4. Are those folks going to have to completely rewrite their components for T5 and put them back out there, thus creating 3 different versions to maintain? -Original Message- From: Danny Angus [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 9: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]
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]
RE: Tapestry 5 Discussions
"Finally, let's take a sober look" Isn't that a bit much to ask? I mean, who's sober on Tuesday?!?!?! :-) -Original Message- From: Adam Zimowski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 9:35 AM To: Tapestry users Subject: Re: Tapestry 5 Discussions Well, that's not so much suggestion, as what I think is probably best course of action in the long run. Based on what Howard said (going from T4 to T5 is more like from Struts to Tapestry), the whole notion of migration path from T4 to T5 should be considered in the context: "Should I be rewriting my T4 app in another framework?" (Another framework being Tapestry with a version label increased to 5..) That's what's really happening here. And I have to say I fully support Howard, because as someone said earlier in the thread - he's having fun doing it. Well, if T5 is too much for my app where I invested so much time in T4, I will stay on T4 and maintain T4 if I have to. Or maybe someone could maintain it for me. You James? Next to Howard and Jessee you are like the guru many people look up to regarding this stuff. Maybe someone else will take over T4. I don't know, but it's certainly what it looks like may happen. If migrating to another version of the same framework is like rewriting my app in ANOTHER framework, then I say no, thank you. No migration path for me, because I'm staying on what I have. Then, all it takes is one application written on T4 base whose benefits of maintaining T4 outgrow rewriting it in T5, and you got yourself a life T4.x.x.x branch. 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. Again, I think time will tell if T4 will grow into its own thing... On 8/1/06, James Carman <[EMAIL PROTECTED]> wrote: > So, you suggest waiting until the product is completely finished/usable > before worrying about backward compatibility at all? I don't know about > that. It might be wise to consider backward compatibility issues while > architecting it. I don't think it's too early to start raising the red flag > when the person designing it is already saying that it's going to be "very > difficult" to migrate existing applications to T5. I'm not saying that I > think T5 should be completely constrained by backward compatibility > concerns, but it would be good to think "how would I migrate a T4 > application if T5 were architected this way" while making design decisions, > since a migration path has been promised and if it's that difficult to > provide, it may take a long time before a reliable/robust solution comes > out. > > The funny thing is that nobody has really talked about (at least from my > recollection) providing a migration path from T3 to T5 yet, either. That's > going to cover a lot of folks. Many didn't upgrade to T4 because of the > potential headaches. Those people will still be left even further behind in > the dust if there's no easy way for them to migrate their apps to T5. > > -Original Message- > From: Adam Zimowski [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 01, 2006 8:40 AM > To: Tapestry users > Subject: Re: Tapestry 5 Discussions > > There is couple such simple answer to all this: > > 1) Time will tell.. > 2) The beauty of open source.. > > 1) Why all the fuss about this NOW? T5 isn't going to happen for a > while yet, so why all that stress about something that you can't use > yet? Use T4, support it, pretend T5 isn't there (because it isn't), > and when T5 comes out make the decision to move onto T5 OR see the 2nd > point below. > > 2) I see this as a GOLDEN opportunity to all those who are looking for > fame and success in the open source world. I mean, here you are handed > a chance to take over a successfull open source project (T4) with > ALREADY ESTABLISHED USER BASE that is HUNGRY for future support of the > product. So if T5 is not for everyone, and T4 as it seems to be > reapeated by many, has lots of room to grow, why not fork T4 when the > time comes and move on with life? > > On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Yes really...That is pretty horribly inappropriate. > > > > Reading the spindle blog doesn't even give me the impression Geoff has run > > off to make babies with GWT either. In fact, it looks like he just > released > > a T4 compatible spindle plugin. > > > > Please keep your personal attacks for some other forum, like a private > email > > or your own website. They aren't appropriate/wanted/appreciated here. > > > > thanks > >
Re: Tapestry 5 Discussions
Well, that's not so much suggestion, as what I think is probably best course of action in the long run. Based on what Howard said (going from T4 to T5 is more like from Struts to Tapestry), the whole notion of migration path from T4 to T5 should be considered in the context: "Should I be rewriting my T4 app in another framework?" (Another framework being Tapestry with a version label increased to 5..) That's what's really happening here. And I have to say I fully support Howard, because as someone said earlier in the thread - he's having fun doing it. Well, if T5 is too much for my app where I invested so much time in T4, I will stay on T4 and maintain T4 if I have to. Or maybe someone could maintain it for me. You James? Next to Howard and Jessee you are like the guru many people look up to regarding this stuff. Maybe someone else will take over T4. I don't know, but it's certainly what it looks like may happen. If migrating to another version of the same framework is like rewriting my app in ANOTHER framework, then I say no, thank you. No migration path for me, because I'm staying on what I have. Then, all it takes is one application written on T4 base whose benefits of maintaining T4 outgrow rewriting it in T5, and you got yourself a life T4.x.x.x branch. 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. Again, I think time will tell if T4 will grow into its own thing... On 8/1/06, James Carman <[EMAIL PROTECTED]> wrote: So, you suggest waiting until the product is completely finished/usable before worrying about backward compatibility at all? I don't know about that. It might be wise to consider backward compatibility issues while architecting it. I don't think it's too early to start raising the red flag when the person designing it is already saying that it's going to be "very difficult" to migrate existing applications to T5. I'm not saying that I think T5 should be completely constrained by backward compatibility concerns, but it would be good to think "how would I migrate a T4 application if T5 were architected this way" while making design decisions, since a migration path has been promised and if it's that difficult to provide, it may take a long time before a reliable/robust solution comes out. The funny thing is that nobody has really talked about (at least from my recollection) providing a migration path from T3 to T5 yet, either. That's going to cover a lot of folks. Many didn't upgrade to T4 because of the potential headaches. Those people will still be left even further behind in the dust if there's no easy way for them to migrate their apps to T5. -Original Message- From: Adam Zimowski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 8:40 AM To: Tapestry users Subject: Re: Tapestry 5 Discussions There is couple such simple answer to all this: 1) Time will tell.. 2) The beauty of open source.. 1) Why all the fuss about this NOW? T5 isn't going to happen for a while yet, so why all that stress about something that you can't use yet? Use T4, support it, pretend T5 isn't there (because it isn't), and when T5 comes out make the decision to move onto T5 OR see the 2nd point below. 2) I see this as a GOLDEN opportunity to all those who are looking for fame and success in the open source world. I mean, here you are handed a chance to take over a successfull open source project (T4) with ALREADY ESTABLISHED USER BASE that is HUNGRY for future support of the product. So if T5 is not for everyone, and T4 as it seems to be reapeated by many, has lots of room to grow, why not fork T4 when the time comes and move on with life? On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > Yes really...That is pretty horribly inappropriate. > > Reading the spindle blog doesn't even give me the impression Geoff has run > off to make babies with GWT either. In fact, it looks like he just released > a T4 compatible spindle plugin. > > Please keep your personal attacks for some other forum, like a private email > or your own website. They aren't appropriate/wanted/appreciated here. > > thanks > > > On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > > > ... And that's why Geoff Longman dropped off the boat to pursue something > > more innovative (GWT) having a solid backing by a reputable company. Not > > with by a sole Saddam-like dictator like Howard. He pretends he's > > democratic > > by throwing his ideas under the umbrella "Discuss" but meanwhile he's made > > up his mind already and won't thus listen to anyone. He didn't listen to > > Geoff that's why
RE: Tapestry 5 Discussions
So, you suggest waiting until the product is completely finished/usable before worrying about backward compatibility at all? I don't know about that. It might be wise to consider backward compatibility issues while architecting it. I don't think it's too early to start raising the red flag when the person designing it is already saying that it's going to be "very difficult" to migrate existing applications to T5. I'm not saying that I think T5 should be completely constrained by backward compatibility concerns, but it would be good to think "how would I migrate a T4 application if T5 were architected this way" while making design decisions, since a migration path has been promised and if it's that difficult to provide, it may take a long time before a reliable/robust solution comes out. The funny thing is that nobody has really talked about (at least from my recollection) providing a migration path from T3 to T5 yet, either. That's going to cover a lot of folks. Many didn't upgrade to T4 because of the potential headaches. Those people will still be left even further behind in the dust if there's no easy way for them to migrate their apps to T5. -Original Message- From: Adam Zimowski [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 01, 2006 8:40 AM To: Tapestry users Subject: Re: Tapestry 5 Discussions There is couple such simple answer to all this: 1) Time will tell.. 2) The beauty of open source.. 1) Why all the fuss about this NOW? T5 isn't going to happen for a while yet, so why all that stress about something that you can't use yet? Use T4, support it, pretend T5 isn't there (because it isn't), and when T5 comes out make the decision to move onto T5 OR see the 2nd point below. 2) I see this as a GOLDEN opportunity to all those who are looking for fame and success in the open source world. I mean, here you are handed a chance to take over a successfull open source project (T4) with ALREADY ESTABLISHED USER BASE that is HUNGRY for future support of the product. So if T5 is not for everyone, and T4 as it seems to be reapeated by many, has lots of room to grow, why not fork T4 when the time comes and move on with life? On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > Yes really...That is pretty horribly inappropriate. > > Reading the spindle blog doesn't even give me the impression Geoff has run > off to make babies with GWT either. In fact, it looks like he just released > a T4 compatible spindle plugin. > > Please keep your personal attacks for some other forum, like a private email > or your own website. They aren't appropriate/wanted/appreciated here. > > thanks > > > On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > > > ... And that's why Geoff Longman dropped off the boat to pursue something > > more innovative (GWT) having a solid backing by a reputable company. Not > > with by a sole Saddam-like dictator like Howard. He pretends he's > > democratic > > by throwing his ideas under the umbrella "Discuss" but meanwhile he's made > > up his mind already and won't thus listen to anyone. He didn't listen to > > Geoff that's why there's no Spindle for Tap 4. Now he claims on his blog > > that tooling is not important. Howard, maybe not to you, but let me > > educate > > you that there is a vast number of people out there who think otherwise. > > It's time you stop imposing your opinions on people. Remember, Wicket has > > stolen a market share from Tapestry. Now there is GWT. Just wait until GWT > > goes out of beta. I promiss you the following statements would hold in the > > very near future: > > > > Tapestry = a+b; > > Wicket = Tapestry - a; > > GWT = Tapestry - b; > > > > Therefore Tapestry = 0. This would be the result by the time the > > incompatible and crazy Tap 5.0 is released. And I would hand you a tissue > > paper to wipe off your hot tears. > > > > Regards, > > F > > > > > > On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > Howard, I know you're very innovative and all, but doesn't this really > > > sound > > > somewhat crazy to you? If you really want Tapestry to gain acceptance, > > > then > > > backward compatibility is a big issue. I jumped into the Tapestry world > > > with the 4.0 release and I'm really enjoying it, but if switching to > > 5.xis > > > going to be "VERY difficult", then I don't know if I'll ever upgrade. > > > Tapestry is definitely (IMHO) very superior to the "standard" JSF, but > > if > > > it > &
Re: Tapestry 5 Discussions
There is couple such simple answer to all this: 1) Time will tell.. 2) The beauty of open source.. 1) Why all the fuss about this NOW? T5 isn't going to happen for a while yet, so why all that stress about something that you can't use yet? Use T4, support it, pretend T5 isn't there (because it isn't), and when T5 comes out make the decision to move onto T5 OR see the 2nd point below. 2) I see this as a GOLDEN opportunity to all those who are looking for fame and success in the open source world. I mean, here you are handed a chance to take over a successfull open source project (T4) with ALREADY ESTABLISHED USER BASE that is HUNGRY for future support of the product. So if T5 is not for everyone, and T4 as it seems to be reapeated by many, has lots of room to grow, why not fork T4 when the time comes and move on with life? On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Yes really...That is pretty horribly inappropriate. Reading the spindle blog doesn't even give me the impression Geoff has run off to make babies with GWT either. In fact, it looks like he just released a T4 compatible spindle plugin. Please keep your personal attacks for some other forum, like a private email or your own website. They aren't appropriate/wanted/appreciated here. thanks On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > ... And that's why Geoff Longman dropped off the boat to pursue something > more innovative (GWT) having a solid backing by a reputable company. Not > with by a sole Saddam-like dictator like Howard. He pretends he's > democratic > by throwing his ideas under the umbrella "Discuss" but meanwhile he's made > up his mind already and won't thus listen to anyone. He didn't listen to > Geoff that's why there's no Spindle for Tap 4. Now he claims on his blog > that tooling is not important. Howard, maybe not to you, but let me > educate > you that there is a vast number of people out there who think otherwise. > It's time you stop imposing your opinions on people. Remember, Wicket has > stolen a market share from Tapestry. Now there is GWT. Just wait until GWT > goes out of beta. I promiss you the following statements would hold in the > very near future: > > Tapestry = a+b; > Wicket = Tapestry - a; > GWT = Tapestry - b; > > Therefore Tapestry = 0. This would be the result by the time the > incompatible and crazy Tap 5.0 is released. And I would hand you a tissue > paper to wipe off your hot tears. > > Regards, > F > > > On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > Howard, I know you're very innovative and all, but doesn't this really > > sound > > somewhat crazy to you? If you really want Tapestry to gain acceptance, > > then > > backward compatibility is a big issue. I jumped into the Tapestry world > > with the 4.0 release and I'm really enjoying it, but if switching to > 5.xis > > going to be "VERY difficult", then I don't know if I'll ever upgrade. > > Tapestry is definitely (IMHO) very superior to the "standard" JSF, but > if > > it > > keeps becoming a "moving target", then it will never gain market > > acceptance. > > The big wigs will win out because they support a "standard." If > Tapestry > > has the reputation of becoming the "consultant's framework" (as has been > > said in the past) because it requires so much work to upgrade, then it's > > going to suffer. It's not that I disagree with the direction you're > > heading. It's that I don't know whether or not changing paradigms so > > drastically is a good idea for the health of the "product" or "brand." > > > > I agree so far with what you're doing. I don't like the fact that > you're > > switching from HiveMind to TapIoCa (that's my little nickname for the > > Tapestry IoC container), but if you don't want to be tied to HiveMind or > > don't want to be constrained by the release schedule, then I understand > > (although you're a big part of the HiveMind community and we can easily > > accommodate any changes you could need IMHO). Anyway, this is your > baby, > > but if you want to gain some market share, then you should really listen > > to > > your users. Tapestry is starting to get a bad reputation for not > > supporting > > backward compatibility. Again, I think the direction you're heading is > a > > good one, if you don't have to consider your current users, but we don't > > have that luxury. > > > > > > -Original Messa
Re: Tapestry 5 Discussions
Although i haven't really had the chance to use tapestry , i have been around it since tap3. Passing from t3 to t4 meant simplification and.. removing almost half of the t3 code. (tried it on my sample applications ) I can imagine that t5 would be again much simple than t4 , keeping the overall concepts the same. As it concerns us , the users , building a component i don't see it much different , except that there will not be anymore the "abstract" thing (again , a simplification) So is not at all a relearning.. should be more of a reshaping in the right way.. Once you knew t3 , t4 seemed easier. Now that you know t4 .. i hope t5 would be a piece of cake ! ;) Though , I understand the business facet of the of the discussion... business rules the world, isn't it ? (mcDonald's is also maintained by a a large comunity of users .. ;) ) Alex On 7/31/06, hv @ Fashion Content <[EMAIL PROTECTED]> wrote: Trashing HiveMind is sort of uninformed(not trying to sling mud). As previously pointed out you can't really do contributions in Spring. And that was one of the key T3 features it was supposed to replace. While I'm not terribly happy about the multitude of concepts involved in writing a non-trivial Tap4 app, I bet it would have been much worse if it had been built on Spring. Being a bit blunt: If you think HiveMind is just an ego trip why dont you write a version of ApplicationServlet that uses Spring instead. If the two are equal it shouldn't be much of a challenge to swap HiveMind out. Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
Trashing HiveMind is sort of uninformed(not trying to sling mud). As previously pointed out you can't really do contributions in Spring. And that was one of the key T3 features it was supposed to replace. While I'm not terribly happy about the multitude of concepts involved in writing a non-trivial Tap4 app, I bet it would have been much worse if it had been built on Spring. Being a bit blunt: If you think HiveMind is just an ego trip why dont you write a version of ApplicationServlet that uses Spring instead. If the two are equal it shouldn't be much of a challenge to swap HiveMind out. Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
I think Howard has already pointed out that it would break the scalability
of Tapestry.
Pages and components instances must maintain their structure or they cannot
be reused between requests.
I think its a very good point, but I suspect that using proxies it would be
possible to support it to some extent by allowing
temporary "extensions" to the defined page/component structure.
Henrik
"Josh Long" <[EMAIL PROTECTED]> skrev i en meddelelse
news:[EMAIL PROTECTED]
Oh, simply to be able to dynamically modify the pages component graph
programatically.
For example, something like you might do in Swing, or Echo, or Wicket,
or PRADO or .NET or JSF or GWT or anything else..
// echo
add(new Link("link") { public void onClick() { } });
// swing
getContentPane().add(new JButton("Hello") , null ) );
// echo
Window window = new Window();
ContentPane content = new ContentPane();
window.setContent(content);
Label label = new Label("Hello, World!");
content.add(label);
// ASP.NET
Button newButton = new Button();
newButton.Text = "New Button";
newButton.ID = "newButton";
newButton.Click += new System.EventHandler(this.newButton_Click);
this.PlaceHolder.Add(newButton);
etc.
I know the reason (and its very, very valid) behind the limitation in
tapestry: applications scale better when the application needs to
maintain only the data for a particular request bound to the page and
not data on the page component graph itself... but theres got to be
some sort of compromise. being able to dynamically add controls is
what makes things like a portal or even a module mechanism feasible..
I hope this is clearer...
Peace,
Josh
On 7/31/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
> Hi,
>
> what exactly do you mean with " to add components programatically" ?
>
> Regards,
>
> > -Ursprüngliche Nachricht-
> > Von: Josh Long [mailto:[EMAIL PROTECTED]
> > Gesendet: Sonntag, 30. Juli 2006 22:52
> > An: Tapestry users
> > Betreff: Re: Tapestry 5 Discussions
>
> > Actually, the one feature I think id like to see at this
> > point (save for some small its-still-not-final issues with
> > tapestry 4.1) is the ability to add components programatically.
> >
>
>
> -
> 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]
Re: Tapestry 5 Discussions
> What do you think? I think; trying out a different approach in a sandbox to achieve improvements that seem impossible with the current structure is a good thing. making up your mind early that the future needs another painful revolution is a bad thing. But for all I know Howard is just trying out some ideas that he thinks are probable key components in a future version of Tapestry. I also think that we should put some action behind our words and chip in to help improve the version 4 line. Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
Personally I don't believe the proposed changes are a significant shift in the concept of how Tapestry works when compared to version 4. If that is the case the upgrade from 4 to 5 would be a technical change only. On the technical part I should think that a "classic" API could exist in Tapestry 5 to support the most common T4 constructs such as the abstract page/component classes. hivemodule.xml could be parsed to generate annotations and/or TODO comments. Henrik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
Oh, simply to be able to dynamically modify the pages component graph
programatically.
For example, something like you might do in Swing, or Echo, or Wicket,
or PRADO or .NET or JSF or GWT or anything else..
// echo
add(new Link("link") { public void onClick() { } });
// swing
getContentPane().add(new JButton("Hello") , null ) );
// echo
Window window = new Window();
ContentPane content = new ContentPane();
window.setContent(content);
Label label = new Label("Hello, World!");
content.add(label);
// ASP.NET
Button newButton = new Button();
newButton.Text = "New Button";
newButton.ID = "newButton";
newButton.Click += new System.EventHandler(this.newButton_Click);
this.PlaceHolder.Add(newButton);
etc.
I know the reason (and its very, very valid) behind the limitation in
tapestry: applications scale better when the application needs to
maintain only the data for a particular request bound to the page and
not data on the page component graph itself... but theres got to be
some sort of compromise. being able to dynamically add controls is
what makes things like a portal or even a module mechanism feasible..
I hope this is clearer...
Peace,
Josh
On 7/31/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
Hi,
what exactly do you mean with " to add components programatically" ?
Regards,
> -Ursprüngliche Nachricht-
> Von: Josh Long [mailto:[EMAIL PROTECTED]
> Gesendet: Sonntag, 30. Juli 2006 22:52
> An: Tapestry users
> Betreff: Re: Tapestry 5 Discussions
> Actually, the one feature I think id like to see at this
> point (save for some small its-still-not-final issues with
> tapestry 4.1) is the ability to add components programatically.
>
-
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]
Re: Tapestry 5 Discussions
> In my personal ideal world, Spring would have implemented the > namespacing, > abstraction, visibility and distributed configuration features he > needs, and > we could all reuse our Spring knowledge when we find we need to extend > Tap5. > At this point all I can hope for is that they implement some of that > stuff > in time for Tap6 :-) Why? Tapestry is apparently not interested in backwards compatibility and the rest of all the shebang! :-) My very personal 2c. But before I continu, I'll explain my situation (probably very much like others here on the list). For 2 recent missions I wanted to use Tapestry as a solution for the clients problem. In both cases we did a proper market research and both times Tap4 came out as being the best, be it not the simplest of them. Anyway, none of the project completed succesfully for several reasons that had nothing to do with Tap4 as such but one of the complaints was that Tap4 was to hard to learn (this might say something about the clients dev team but that's beside the point). I can't say that I'm very knowledgeable in the mystic art of Tap4. I try but since my current assignment does not include Tap4, and my free time is a rare commodity, I'm just lurking on the list to try to keep up. My worries are indeed that if Tap5 breaks all ties with Tap4, I will again have to invest lots of time in something that does *not* garantee any backwardscompatibility. For me, being a contractor, it does not realy makes an issue since once the job is done, I move on. But I can't sell that to the client! They want the illusion of things being able to run for years and years. Also, since the java world is moving very fast (with lots of framworks, lots of choice), haveing to relearn the same thing over and over is kinda tiresome and might changes the selection criteria I use for selecting a framework in the future. In conclusion, change is good, progress does come at a cost but support comes from the community. No one wants a high-tech, top-notch framework that is only sustained by a group of fanatical persons. I sounds good, but it doesn't sell. Not now, never will. BB Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
If theres a migration path to be had, then Im more than interested in tapestry 5. Actually, the one feature I think id like to see at this point (save for some small its-still-not-final issues with tapestry 4.1) is the ability to add components programatically. Everything else seems to be on par or better with anything else out there (PRADO, ASP.NET, Echo, Wicket, JSF (eew)...) (in both technical merit and usability) As to the migration path, im not even saying Im opposed to using an evil regex requiring a cluster of perl installations and some holy water to work ;-) if that's what it takes, but its got to be in place. Peace, Josh On 7/30/06, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: Nice, Now it would be great if some of the people who complain about lack of stability actually helped in the migration path. I see some people who are pretty old Tapestry users. -- Ing. Leonardo Quijano Vincenzi DTQ Software Web Application Design and Programming http://www.dtqsoftware.com Jesse Kuhnert escribió: > I really don't see what all the fuss is about anymore. I've already > stated > that I'll be providing "some" form of T4 extension to upgrade to T5 > when the > time comes for it. > > I've been wanting some of the features in T5 almost since the first day I > started using Tapestry. I'm willing to go through the pain of > developing a > T4 upgrade extension to it if that's what it takes to get me there. I > feel > very comforatable with most of the code in T4 now . > > So..There we have it. :) - 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]
Re: Tapestry 5 Discussions
Nice, Now it would be great if some of the people who complain about lack of stability actually helped in the migration path. I see some people who are pretty old Tapestry users. -- Ing. Leonardo Quijano Vincenzi DTQ Software Web Application Design and Programming http://www.dtqsoftware.com Jesse Kuhnert escribió: I really don't see what all the fuss is about anymore. I've already stated that I'll be providing "some" form of T4 extension to upgrade to T5 when the time comes for it. I've been wanting some of the features in T5 almost since the first day I started using Tapestry. I'm willing to go through the pain of developing a T4 upgrade extension to it if that's what it takes to get me there. I feel very comforatable with most of the code in T4 now . So..There we have it. :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
Jesse Kuhnert wrote: > I really don't see what all the fuss is about anymore. I've already stated > that I'll be providing "some" form of T4 extension to upgrade to T5 when > the > time comes for it. > So..There we have it. :) > Great! After T3 betas/RCs, T4, I'm looking forward to migrate all our apps also to T4.1, T5... It's the best Java web framework out there and news like this it what we need to convince business people that it'll remain the best one and there will be a way to upgrade. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
liigo wrote: > tapestry is a open source project. > before you requires others do or not do something, think what you have > done for it. > don't selfish It'll be selfish keeping my opinions for myself instead of sharing them. I doubt this discussion aimed to be one about what open source is or means. This certainly isn't a thread to collect "requirements", so I hope I wasn't misunderstood when sharing my thoughts about things I like or not like to see in future versions. Hopefully one doesn't need to start each sentence with "I wished Tapestry could probably..." as it seemed clear to me that committers decide anyway. The point however is that this thread certainly intends that the user base shares opinions in order not to overlook things or the user base. Basically what the user base of any open source project can do is to use the software, be active on mailing lists and suggest it's future use. Something that happend a lot in the past 2 years (since March 2004, so I know my share...), but this also should mean some kind of responsibilty for the project not leaving people alone after adoption. Offering a migration path is something most people on this list obviously would appreciate at least. In the end, suggesting Tapestry's use to customers means more people having Tapestry know-how, buying Tapestry books, being more active on the list, probably even bug fixing or committing code and spreading the whole thing. Hoping to read more arguments pro Tapestry5 when asked, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
I really don't see what all the fuss is about anymore. I've already stated that I'll be providing "some" form of T4 extension to upgrade to T5 when the time comes for it. I've been wanting some of the features in T5 almost since the first day I started using Tapestry. I'm willing to go through the pain of developing a T4 upgrade extension to it if that's what it takes to get me there. I feel very comforatable with most of the code in T4 now . So..There we have it. :) On 7/30/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: this is a very simple minded thinking, liigo... what would an OS project be without the thousands that use it ? - that tell u what is needed/ not needed ? the businessfolks that use it ? contributing means more than just adding some line of code... im in a position where i choose the technology used for our company by myself, and the current discussion about migrationpath is the basic for all business decisions followed. to be clearly: if there is no migration path, i will see no use in using tapestry4 and 5 - no matter how good they are ! when telling about business applications, i have apps in mind that run 10, 20 years and more - so a basic upgrade path is necessary for at least some time, as we all have different problems than just the framework to be solved. choosing an technology usually implies using it a long time - and there u need a future vision regards, korbinian > -Ursprüngliche Nachricht- > Von: liigo [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 30. Juli 2006 15:38 > An: Tapestry users > Betreff: Re: Tapestry 5 Discussions > > tapestry is a open source project. > before you requires others do or not do something, think what > you have done for it. > don't selfish > > 2006/7/30, Michael Echerer <[EMAIL PROTECTED]>: > > Norbert Sándor wrote: > > > - rethink the IOC container of t5 (use hivemind 2.0 or > maybe Spring > > > instead of a custom "unsupported" solution) > > I also agree that we shouldn't have another IoC container. > Spring is > > the de facto standard. Either take Spring and work around > missing features. > > E.g. use naming conventions instead of namespaces or whatever until > > Spring adds this, or stick to Hivemind and enhance this IoC > container > > to meet T5 needs. > > > - t5 should come with a compatibility layer for t4.X. > Jesse "promised" > > > this but Howard said nothing about it. > > +1... At least T4 users need a migration guide like the one we used > > +when > > migrating from T3 to T4. If it's a mechanical task it might be okay > > even if we need to trash a lot. Without a proper replacement guide > > however users either won't migrate to T5 or the will > migrate away from Tapestry. > > > - the development resources should be focused first on the 4.1 > > > branch, because the competing development of 4.1 and 5 delays the > > > release of 4.1. Users of t4 are currently waiting for 4.1, not 5. > > > - the most important one: pay more attention to the needs of the > > > current users - without them tapestry would be dead... > > Certainly true. Don't forget that Tapestry is a Apache top-level > > project. That means "stability" and "maturity", too. > > > > Tapestry should evolve to maintain its large user base. > It's not yet > > time for another revolution! > > > > There are lot's of Tapestry applications out there - even > dozends that > > made it from T3 release candidates to T4 final ;-) - that should be > > maintainable in future and we need a path to T5. No need for a > > revolution for T5, maybe for T6 again, but T5 should be an > improvement > > release first. > > A revolution now, might lead to a community split (T4 vs. > T5) or even > > cause Tapestry to die in the rise of JSF. The best > framework won't be > > choosen if you can't build on it because it remains a moving target. > > > > Developing for a moving target is something difficult to explain to > > business people. Explaining to develop using a best-of-breed GUI > > framework instead of JSF & Co., because it's a, b, c, d, e, > does f,g,h > > better is easy, if you can tell them that an even better Tx > is on the > > way we can upgrade to, instead of waiting for the > vendor-driven JSF process. > > > > > Cheers, > > Michael > > > > > > > > > - > > 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] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: Tapestry 5 Discussions
"don't selfish" does not help anything. Sigh On 7/30/06, liigo <[EMAIL PROTECTED]> wrote: tapestry is a open source project. before you requires others do or not do something, think what you have done for it. don't selfish 2006/7/30, Michael Echerer <[EMAIL PROTECTED]>: > Norbert Sándor wrote: > > - rethink the IOC container of t5 (use hivemind 2.0 or maybe Spring > > instead of a custom "unsupported" solution) > I also agree that we shouldn't have another IoC container. Spring is the > de facto standard. Either take Spring and work around missing features. > E.g. use naming conventions instead of namespaces or whatever until > Spring adds this, or stick to Hivemind and enhance this IoC container to > meet T5 needs. > > - t5 should come with a compatibility layer for t4.X. Jesse "promised" > > this but Howard said nothing about it. > +1... At least T4 users need a migration guide like the one we used when > migrating from T3 to T4. If it's a mechanical task it might be okay even > if we need to trash a lot. Without a proper replacement guide however > users either won't migrate to T5 or the will migrate away from Tapestry. > > - the development resources should be focused first on the 4.1 branch, > > because the competing development of 4.1 and 5 delays the release of > > 4.1. Users of t4 are currently waiting for 4.1, not 5. > > - the most important one: pay more attention to the needs of the current > > users - without them tapestry would be dead... > Certainly true. Don't forget that Tapestry is a Apache top-level > project. That means "stability" and "maturity", too. > > Tapestry should evolve to maintain its large user base. It's not yet > time for another revolution! > > There are lot's of Tapestry applications out there - even dozends that > made it from T3 release candidates to T4 final ;-) - that should be > maintainable in future and we need a path to T5. No need for a > revolution for T5, maybe for T6 again, but T5 should be an improvement > release first. > A revolution now, might lead to a community split (T4 vs. T5) or even > cause Tapestry to die in the rise of JSF. The best framework won't be > choosen if you can't build on it because it remains a moving target. > > Developing for a moving target is something difficult to explain to > business people. Explaining to develop using a best-of-breed GUI > framework instead of JSF & Co., because it's a, b, c, d, e, does f,g,h > better is easy, if you can tell them that an even better Tx is on the > way we can upgrade to, instead of waiting for the vendor-driven JSF process. > > > Cheers, > Michael > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Tapestry 5 Discussions
tapestry is a open source project. before you requires others do or not do something, think what you have done for it. don't selfish 2006/7/30, Michael Echerer <[EMAIL PROTECTED]>: Norbert Sándor wrote: > - rethink the IOC container of t5 (use hivemind 2.0 or maybe Spring > instead of a custom "unsupported" solution) I also agree that we shouldn't have another IoC container. Spring is the de facto standard. Either take Spring and work around missing features. E.g. use naming conventions instead of namespaces or whatever until Spring adds this, or stick to Hivemind and enhance this IoC container to meet T5 needs. > - t5 should come with a compatibility layer for t4.X. Jesse "promised" > this but Howard said nothing about it. +1... At least T4 users need a migration guide like the one we used when migrating from T3 to T4. If it's a mechanical task it might be okay even if we need to trash a lot. Without a proper replacement guide however users either won't migrate to T5 or the will migrate away from Tapestry. > - the development resources should be focused first on the 4.1 branch, > because the competing development of 4.1 and 5 delays the release of > 4.1. Users of t4 are currently waiting for 4.1, not 5. > - the most important one: pay more attention to the needs of the current > users - without them tapestry would be dead... Certainly true. Don't forget that Tapestry is a Apache top-level project. That means "stability" and "maturity", too. Tapestry should evolve to maintain its large user base. It's not yet time for another revolution! There are lot's of Tapestry applications out there - even dozends that made it from T3 release candidates to T4 final ;-) - that should be maintainable in future and we need a path to T5. No need for a revolution for T5, maybe for T6 again, but T5 should be an improvement release first. A revolution now, might lead to a community split (T4 vs. T5) or even cause Tapestry to die in the rise of JSF. The best framework won't be choosen if you can't build on it because it remains a moving target. Developing for a moving target is something difficult to explain to business people. Explaining to develop using a best-of-breed GUI framework instead of JSF & Co., because it's a, b, c, d, e, does f,g,h better is easy, if you can tell them that an even better Tx is on the way we can upgrade to, instead of waiting for the vendor-driven JSF process. > Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry 5 Discussions -- Nice to see people paying attention
First of all, let me say that I don't appreciate the name-calling. I am not personally attacking anyone here. I am a very active member of the open source community and I too do it because I enjoy it. I enjoy working with Tapestry and I believe that Tapestry is a very well-designed framework. That's why I feel so strongly about its future. The only real issue that I have is that there's no migration path. As many others on this thread have agreed, no migration path really makes the businessey folks very nervous and they might not let us techey folks use Tapestry because of it and that would be a shame. I have read the documentation on the new IoC container and I've already started discussion with the HiveMind team about including some of Howard's concepts into HiveMind itself. That's not an argument that Tapestry should keep HiveMind, but an illustration that I actually do support the direction that Tapestry is heading with the new IoC container. James p.s. Sorry to dual post, but this thread got splintered onto both lists. -Original Message- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Saturday, July 29, 2006 10:07 AM To: Tapestry development Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention Wow, I have to say I'm pretty disappointed in such talk from someone who is supposed to be the "chairman" of Hivemind. I'd almost say it sounds kind of immature. I support Howard's work on T5 completely, and since he and I are currently the two most active developers I think it has to count for something. We do this because we enjoy it, please don't try and take that away. If you think you can do a better job the door is always open. It ~is~ open source after all :) On 7/29/06, James Carman <[EMAIL PROTECTED]> wrote: > > Again, Howard, don't get me wrong. I really like some of the cool new > stuff > you're doing with Tap5, except for maybe Tapioca (that's not the official > name, but my "pet" name) vs. HiveMind. Anyway, one might interpret what > you've basically said here: > > "future users vastly outnumber the current users" > > to mean that you don't mind leaving your current users out in the cold > when > it comes to the future of Tapestry. I'm not saying that's what you said, > necessarily, but I'm saying it could be interpreted that way. > > 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." > > 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. > > -Original Message- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, July 28, 2006 6:12 PM > To: Tapestry development > Subject: Re: Tapestry 5 Discussions -- Nice to see people paying attention > > The current state of the T4 code is untenable w.r.t. to adding new > features without breaking backwards compatibility. Each upgrade of > Tapestry (2 to 3 to 4) has had major upgrade problems because of a > number of factors, mostly the design of the APIs and the need to > extend from base classes (as the base classes provide much of the > component functionality). > > In the long view of Tapestry, the future users vastly outnumber the > current users. Tapestry 5 is targetting that group of users. > > Existing applications coded to Tapestry 4 ... well, leave them on > Tapestry 4! Many users prefer to stay on Tapestry 3. They don't want > to face the upgrade from 3 to 4 if their application is working. The > design of Tapestry 5 will facilitate easy upgrades from 5 on ... > mainly because the A
Re: Tapestry 5 Discussions
Norbert Sándor wrote: > - rethink the IOC container of t5 (use hivemind 2.0 or maybe Spring > instead of a custom "unsupported" solution) I also agree that we shouldn't have another IoC container. Spring is the de facto standard. Either take Spring and work around missing features. E.g. use naming conventions instead of namespaces or whatever until Spring adds this, or stick to Hivemind and enhance this IoC container to meet T5 needs. > - t5 should come with a compatibility layer for t4.X. Jesse "promised" > this but Howard said nothing about it. +1... At least T4 users need a migration guide like the one we used when migrating from T3 to T4. If it's a mechanical task it might be okay even if we need to trash a lot. Without a proper replacement guide however users either won't migrate to T5 or the will migrate away from Tapestry. > - the development resources should be focused first on the 4.1 branch, > because the competing development of 4.1 and 5 delays the release of > 4.1. Users of t4 are currently waiting for 4.1, not 5. > - the most important one: pay more attention to the needs of the current > users - without them tapestry would be dead... Certainly true. Don't forget that Tapestry is a Apache top-level project. That means "stability" and "maturity", too. Tapestry should evolve to maintain its large user base. It's not yet time for another revolution! There are lot's of Tapestry applications out there - even dozends that made it from T3 release candidates to T4 final ;-) - that should be maintainable in future and we need a path to T5. No need for a revolution for T5, maybe for T6 again, but T5 should be an improvement release first. A revolution now, might lead to a community split (T4 vs. T5) or even cause Tapestry to die in the rise of JSF. The best framework won't be choosen if you can't build on it because it remains a moving target. Developing for a moving target is something difficult to explain to business people. Explaining to develop using a best-of-breed GUI framework instead of JSF & Co., because it's a, b, c, d, e, does f,g,h better is easy, if you can tell them that an even better Tx is on the way we can upgrade to, instead of waiting for the vendor-driven JSF process. > Cheers, Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
First, we all know that tapestry is open source. But please don't forget that a project cannot live without its "simple" users. You cannot simply say that future users will outnumber the current users - first, you cannot be sure and the most important is that potential future users will think about whether t6 will have the same slogan? We all thank the hard work of the committers (especially Howard and Jesse), but the "Tapestry 5 Discussions" thread shows that there are some important things to note: - rethink the IOC container of t5 (use hivemind 2.0 or maybe Spring instead of a custom "unsupported" solution) - t5 should come with a compatibility layer for t4.X. Jesse "promised" this but Howard said nothing about it. - the development resources should be focused first on the 4.1 branch, because the competing development of 4.1 and 5 delays the release of 4.1. Users of t4 are currently waiting for 4.1, not 5. - the most important one: pay more attention to the needs of the current users - without them tapestry would be dead... What do you think? Regards, Norbi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
I completely agree with you since myself is also very techie. While, if I put the business hat on, things are viewed very differently. I personally have so much experience in this area. Being a Architect, I have to work with different people at different levels, developers, managers, project managers, client managers, client support, bisiness analysts, client architect group, sales, et al. One proposal or solution will go through reviews, reviews. For any solution, you need to have strong arguments to support it. It's a very hard time for me. I like the new ideas, I like to explore new technologies. But please give a path to upgrade, it's very very important to the business world. You know what dirve a company to upgrade: the support, the liveliness of a product. No upgrade path, it's viewed as a bad investment. We had a project that use SilverStream, when it was aquired by Novell. The SilverStream programming model is desupported and no conversion or upgrade path to J2EE are provided. We have to rewrite. Do we use SilverStream any more? No. I chose Tapestry at first and completed a prototype with Tapestry 4 and dojo. Now the project started, I stopped Tapestry, use dojo completely. One of the reasons is the future of Tapestry is very unclear to me. It is a very risky thing to use Tapestry in a company setting. I think that Tapestry is still in a stage for consultants. To make Tapestry into the mainstream, Tapestry needs to be run like a business. Otherwise, ... ... Although I dropped Tapestry, I still think that Tapestry has some technical advantages, I will continue follow up Tapestry. Wish Tapestry have a good future. On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Yes, I could imagine doing it. We did the same thing when I worked at a large consulting company. I wanted to leave after the first 4 months(you can only learn so much with vanilla servlets + templating language enhancements), but stayed on to see through to the end on a project they started me on. The only problem with one solid way of doing things "forever" - combined with the only change being clients/products that you don't get to maintain - is that you have a tough juggling act to manage keeping and hiring good engineers, but not quite so good that they quickly become bored and leave. Surely with all of those people swimming around not everyone is beaming with happiness to be doing one thing all the time? On 7/28/06, Steven Bell <[EMAIL PROTECTED]> wrote: > > That is one of the reasons. There are others. > > In my company we have many (possibly upwords of twenty) web projects going > at any one time in various stages of development. The ability for a > developer from one project to move to, and be productive in, another > project > as priority and resources demand is critical. > > With this in mind we simply wouldn't be able move new projects to newer > versions of Tapestry even if we could spend the ramp up time learning the > new framework as we couldn't get everybody on the same page. Could you > imagine being on a Tap4 project for several months, then moving to a Tap3 > project for several more, and later getting onto a new project with the > latest Tap5. Just keeping it all straight would drive the average person > nuts. > > On 7/28/06, Jason Dyer <[EMAIL PROTECTED]> wrote: > > > > Because, a company that has invested a year or more, developing an app > is > > probably going to want to use it for a little while. Over the lifetime > of > > an > > enterprise app, it will undoubtedly need modification (both bug fixes > and > > added features.) > > > > When Tapestry 5 arrives, we can safely assume that Tapestry 4 > development > > will > > stop fairly shortly thereafter (new features immediately, maybe bug > fixing > > will go on for a year or two, but that's nothing compared to the > lifetime > > of > > a large app.) Then there's the fact that, right now it's difficult > enough > > to > > find people with skill in T4, but in a couple of years it'll be > > impossible, > > because most people will have moved on to T5... > > > > If the migration to T5 requires what basically amounts to a rewrite and > T4 > > is > > no longer maintainable, then the 'powers that be' at said company are > > going > > to be a little irate that they've invested so much time/money into > > something > > that ultimately didn't last very long. In fact, they'll probably be > > looking > > for heads to roll... > > > > > > On Friday 28 July 2006 18:48, adasal wrote: > > > Seems I am wrong in my earlier post. > > > Emm, but there is a lot of discussion around the need for > compatibility. > > > Why is it so desirable, it seems to posit a large ongoing project that > > > spans both 4 and 5. Why would such a project need to hook up to 5? > > > Adam > > > > > > > -- > > > > -- > > backups: always in season, never out of style. > > > > - > > To unsubscribe, e-m
Re: Tapestry 5 Discussions
This is something that depends on the ability - and the willingness - to learn. There are some people who love staying in one job doing the same thing for years (yeah, they exist, Jesse!), and there are other who can't stand maintaining legacies just because some pointy haired boss is afraid of moving to a new version. I count myself in the last group. So, 2 fallacies, I guess: 1) I don't Tap 5 is as different - conceptually - as you make it sound. At least it has some "philosophy" behind it that's behind the other Tap projects. I think that's important. 2) What prevents us to develop a compatibility layer for Tap 4 over Tap 5? Or even JSF!! Of course it takes community effort, but if there are so many developers interested in it, it could be done (heh Jesse has already promised so). I think that's *the* way of doing backwards compatibility - creating a new, cooler version and providing a plugin for the old one - instead of maintaining large legacy code bases and having the project stagnated to death. What's preferrable? To bloat the current project so much we can't even maintain it? Or to risk losing "stable" people because we add new features? A though one to make, IMO. -- Ing. Leonardo Quijano Vincenzi DTQ Software Web Application Design and Programming http://www.dtqsoftware.com Spencer Crissman escribió: Bingo. The issue isn't that having a Tap5 is important, for it is. There will always be a need to add new features and support new technologies as a framework expands. The issue I have is that every Tap release doesn't just add new abilities, it completely scraps the existing code. There are numerous reasons why this is a poor way of working. Specifically: 1) A framework's is by nature harder to learn than other technologies. This is because unlike learning a particular application, learning a single library, or learning just a class, a framework adds a great deal of complexity in order to be a more general purpose solution. This added complexity results in a steep learning curve, which requires a large investment of time on the part of its users in order to learn. The payoff, or return on that investment of time is the ability to leverage that knowledge on a variety of projects. By rewriting the entire framework with each release, that investment of time is destroyed. Developers barely have time to see a couple of projects through before they have to relearn the new way of doing things. This severely limits the returning value of the framework, and is very wasteful when it comes to developer time. 2) Specific to Tapestry, the framework is based around reusable components. The promise of the existance of these components is very powerful, and could be a source of as much value as the framework itself. By continually invalidating the component libraries that exist, we once again limit the ongoing value of the project. A component based framework ought to have a vibrant user community with a large variety of compnents that will work for a long time. I'm not seeing that happen with Tapestry, despite all its promise. 3) Having a framework that works only for a single snapshot in time may work for some companies that write an application and release it. But really, that is probably more suited to a client side application than a web framework. The reality is that most of the web applications developed in Tapestry 4 will need to be supported in place for a long time. And during that time, feature requests will come in that can only be implemented using the technologies made available in Tap5 or Tap6 or TapX. Developers need to know that when it comes time to add new features, the cost is proportionate to what they are adding. To add a small feature that uses some tiny subset of Tap5 features, I will have to rewrite the entire web application? Again, such a waste of time. 4) One powerful advantage that open source projects have is that there is so much expertise, and so many skilled individuals out there, that working together they should be able to view the project from many different sources, and see many different ways that the project can grow and take shape. This should add some level of flexibility to the projects. There should be some level of forethought from a variety of angles built into the code. The fact that every new release of Tapestry requires a rewrite makes me question just what is going on. Why can't a system be made to work without being so rigid and inflexible that it cannot be adapted in the future? We have so many patterns and so many well understood software design principles exactly to prevent having to do complete rewrites. That a project isn't able or isn't willing to use them for that purpose is worrying, to say the least. This is understandable for a new project, or a young project, but we're talking about version 5 now. 5! 5) Open source projects rely on contributions via mailing list
Re: Tapestry 5 Discussions
Well, here is one nice blog entry about frameworks and backwards compatibility: http://www.weiqigao.com/blog/2006/07/24/software_development_the_abstraction_dilemma.html On 7/29/06, Daniel Honig <[EMAIL PROTECTED]> wrote: I'm shamelessly too intoxicatd to reply, but Ezra encapsulated my thoughts tonight. When he said, Hivemind is about ego, I was silently applauding. I don't understand whey the Tpy community cannot talk to Rod and Jurgen and have an integration. Let's talk .Net and JEE. For hte past year I have been an onanist who has wicked fantacies of elcipse in lace while I slave away shackled to VS.net. The fundamental convepts behind tapestry are 1) not original. 2) not unique to a given language 3) highly productive HLS has done a jaw dropping awesome job of architecting T. But I never understood why spring could not be substituted in place of Hmind. Honestly I always thought Hmind was a case of ego. with much respect and kudos to HLS, I don't know why any implemtation of T, would need a particular DI or IoC container. T is a presentation layer framework. period. If I want to have a bunch of data services screamj out WDSL T. has no use. Well why would T. and Hmind be so married. Most A. projects with notable exceptions, do one thing, and one thing well. If HLS imagines a pure java impl of T. without Hmind, then that is great. I like orthoganality. I think competing with Pico, Spring and raw codw e is a mistake. Why can't we integrate with SpringThat's what my clients want.Guaranteed. Seriously, If I mention Hivemind, people are out' THe proxy we wrote is ok for small interdirectional transfers. Much mor eis needed in reality. On 7/29/06, Spencer Crissman <[EMAIL PROTECTED]> wrote: > > Bingo. > > The issue isn't that having a Tap5 is important, for it is. There will > always be a need to add new features and support new technologies as a > framework expands. The issue I have is that every Tap release doesn't > just > add new abilities, it completely scraps the existing code. There are > numerous reasons why this is a poor way of working. Specifically: > > 1) A framework's is by nature harder to learn than other technologies. > This is because unlike learning a particular application, learning a > single > library, or learning just a class, a framework adds a great deal of > complexity in order to be a more general purpose solution. This added > complexity results in a steep learning curve, which requires a large > investment of time on the part of its users in order to learn. The > payoff, > or return on that investment of time is the ability to leverage that > knowledge on a variety of projects. > > By rewriting the entire framework with each release, that investment of > time > is destroyed. Developers barely have time to see a couple of projects > through before they have to relearn the new way of doing things. This > severely limits the returning value of the framework, and is very wasteful > when it comes to developer time. > > 2) Specific to Tapestry, the framework is based around reusable > components. The promise of the existance of these components is very > powerful, and could be a source of as much value as the framework itself. > By continually invalidating the component libraries that exist, we once > again limit the ongoing value of the project. A component based framework > ought to have a vibrant user community with a large variety of compnents > that will work for a long time. I'm not seeing that happen with Tapestry, > despite all its promise. > > 3) Having a framework that works only for a single snapshot in time may > work for some companies that write an application and release it. But > really, that is probably more suited to a client side application than a > web > framework. The reality is that most of the web applications developed in > Tapestry 4 will need to be supported in place for a long time. And during > that time, feature requests will come in that can only be implemented > using > the technologies made available in Tap5 or Tap6 or TapX. Developers need > to > know that when it comes time to add new features, the cost is > proportionate > to what they are adding. To add a small feature that uses some tiny > subset > of Tap5 features, I will have to rewrite the entire web > application? Again, > such a waste of time. > > 4) One powerful advantage that open source projects have is that there is > so much expertise, and so many skilled individuals out there, that working > together they should be able to view the project from many different > sources, and see many different ways that the project can grow and take > shape. This should add some level of flexibility to the projects. There > should be some level of forethought from a variety of angles built into > the > code. > > The fact that every new release of Tapestry requires a rewrite makes me > question just what is going on. Why can't a system be made to
Re: Tapestry 5 Discussions
I'm shamelessly too intoxicatd to reply, but Ezra encapsulated my thoughts tonight. When he said, Hivemind is about ego, I was silently applauding. I don't understand whey the Tpy community cannot talk to Rod and Jurgen and have an integration. Let's talk .Net and JEE. For hte past year I have been an onanist who has wicked fantacies of elcipse in lace while I slave away shackled to VS.net. The fundamental convepts behind tapestry are 1) not original. 2) not unique to a given language 3) highly productive HLS has done a jaw dropping awesome job of architecting T. But I never understood why spring could not be substituted in place of Hmind. Honestly I always thought Hmind was a case of ego. with much respect and kudos to HLS, I don't know why any implemtation of T, would need a particular DI or IoC container. T is a presentation layer framework. period. If I want to have a bunch of data services screamj out WDSL T. has no use. Well why would T. and Hmind be so married. Most A. projects with notable exceptions, do one thing, and one thing well. If HLS imagines a pure java impl of T. without Hmind, then that is great. I like orthoganality. I think competing with Pico, Spring and raw codw e is a mistake. Why can't we integrate with SpringThat's what my clients want.Guaranteed. Seriously, If I mention Hivemind, people are out' THe proxy we wrote is ok for small interdirectional transfers. Much mor eis needed in reality. On 7/29/06, Spencer Crissman <[EMAIL PROTECTED]> wrote: Bingo. The issue isn't that having a Tap5 is important, for it is. There will always be a need to add new features and support new technologies as a framework expands. The issue I have is that every Tap release doesn't just add new abilities, it completely scraps the existing code. There are numerous reasons why this is a poor way of working. Specifically: 1) A framework's is by nature harder to learn than other technologies. This is because unlike learning a particular application, learning a single library, or learning just a class, a framework adds a great deal of complexity in order to be a more general purpose solution. This added complexity results in a steep learning curve, which requires a large investment of time on the part of its users in order to learn. The payoff, or return on that investment of time is the ability to leverage that knowledge on a variety of projects. By rewriting the entire framework with each release, that investment of time is destroyed. Developers barely have time to see a couple of projects through before they have to relearn the new way of doing things. This severely limits the returning value of the framework, and is very wasteful when it comes to developer time. 2) Specific to Tapestry, the framework is based around reusable components. The promise of the existance of these components is very powerful, and could be a source of as much value as the framework itself. By continually invalidating the component libraries that exist, we once again limit the ongoing value of the project. A component based framework ought to have a vibrant user community with a large variety of compnents that will work for a long time. I'm not seeing that happen with Tapestry, despite all its promise. 3) Having a framework that works only for a single snapshot in time may work for some companies that write an application and release it. But really, that is probably more suited to a client side application than a web framework. The reality is that most of the web applications developed in Tapestry 4 will need to be supported in place for a long time. And during that time, feature requests will come in that can only be implemented using the technologies made available in Tap5 or Tap6 or TapX. Developers need to know that when it comes time to add new features, the cost is proportionate to what they are adding. To add a small feature that uses some tiny subset of Tap5 features, I will have to rewrite the entire web application? Again, such a waste of time. 4) One powerful advantage that open source projects have is that there is so much expertise, and so many skilled individuals out there, that working together they should be able to view the project from many different sources, and see many different ways that the project can grow and take shape. This should add some level of flexibility to the projects. There should be some level of forethought from a variety of angles built into the code. The fact that every new release of Tapestry requires a rewrite makes me question just what is going on. Why can't a system be made to work without being so rigid and inflexible that it cannot be adapted in the future? We have so many patterns and so many well understood software design principles exactly to prevent having to do complete rewrites. That a project isn't able or isn't willing to use them for that purpose is worrying, to say the least. This is understandable for a
Re: Tapestry 5 Discussions
Bingo. The issue isn't that having a Tap5 is important, for it is. There will always be a need to add new features and support new technologies as a framework expands. The issue I have is that every Tap release doesn't just add new abilities, it completely scraps the existing code. There are numerous reasons why this is a poor way of working. Specifically: 1) A framework's is by nature harder to learn than other technologies. This is because unlike learning a particular application, learning a single library, or learning just a class, a framework adds a great deal of complexity in order to be a more general purpose solution. This added complexity results in a steep learning curve, which requires a large investment of time on the part of its users in order to learn. The payoff, or return on that investment of time is the ability to leverage that knowledge on a variety of projects. By rewriting the entire framework with each release, that investment of time is destroyed. Developers barely have time to see a couple of projects through before they have to relearn the new way of doing things. This severely limits the returning value of the framework, and is very wasteful when it comes to developer time. 2) Specific to Tapestry, the framework is based around reusable components. The promise of the existance of these components is very powerful, and could be a source of as much value as the framework itself. By continually invalidating the component libraries that exist, we once again limit the ongoing value of the project. A component based framework ought to have a vibrant user community with a large variety of compnents that will work for a long time. I'm not seeing that happen with Tapestry, despite all its promise. 3) Having a framework that works only for a single snapshot in time may work for some companies that write an application and release it. But really, that is probably more suited to a client side application than a web framework. The reality is that most of the web applications developed in Tapestry 4 will need to be supported in place for a long time. And during that time, feature requests will come in that can only be implemented using the technologies made available in Tap5 or Tap6 or TapX. Developers need to know that when it comes time to add new features, the cost is proportionate to what they are adding. To add a small feature that uses some tiny subset of Tap5 features, I will have to rewrite the entire web application? Again, such a waste of time. 4) One powerful advantage that open source projects have is that there is so much expertise, and so many skilled individuals out there, that working together they should be able to view the project from many different sources, and see many different ways that the project can grow and take shape. This should add some level of flexibility to the projects. There should be some level of forethought from a variety of angles built into the code. The fact that every new release of Tapestry requires a rewrite makes me question just what is going on. Why can't a system be made to work without being so rigid and inflexible that it cannot be adapted in the future? We have so many patterns and so many well understood software design principles exactly to prevent having to do complete rewrites. That a project isn't able or isn't willing to use them for that purpose is worrying, to say the least. This is understandable for a new project, or a young project, but we're talking about version 5 now. 5! 5) Open source projects rely on contributions via mailing lists and/or wikis and tutorial websites to teach developers the ropes. Completely changing the way everything works in every release makes it hard to learn, hard to search for, and hard to establish best practices. You aren't just throwing out code when you scrap a framework, you are throwing out all the knowledge that has accumulated around it. As was mentioned elsewhere in this thread, this isn't a race. Do one thing, and do it well. If hivemind doesn't have the new features, get them done in that project, maintaining backwards compatibility, and then bring them to the Tapestry project for the next release. With so much waste in the world, why are we reinventing the wheel that was specifically reinvented for this same project so recently? In the end, for me, it boils down to this: We are a small company, and our small group of developers will be growing the applications we build over time. We have to look at both the current capabilities, and the future costs of the frameworks we select. While Tapestry's current capabilities are great, the future costs that it will incur if it continues along the path of constant rewrites are too great for us to invest in it. There are many users in the same boat. Why do none of the above points make any difference in the future path of Tapestry? I find it ironic that one of the stated goals on the Tapestry 5 IoC Introdu
Re: Tapestry 5 Discussions
Yes, I could imagine doing it. We did the same thing when I worked at a large consulting company. I wanted to leave after the first 4 months(you can only learn so much with vanilla servlets + templating language enhancements), but stayed on to see through to the end on a project they started me on. The only problem with one solid way of doing things "forever" - combined with the only change being clients/products that you don't get to maintain - is that you have a tough juggling act to manage keeping and hiring good engineers, but not quite so good that they quickly become bored and leave. Surely with all of those people swimming around not everyone is beaming with happiness to be doing one thing all the time? On 7/28/06, Steven Bell <[EMAIL PROTECTED]> wrote: That is one of the reasons. There are others. In my company we have many (possibly upwords of twenty) web projects going at any one time in various stages of development. The ability for a developer from one project to move to, and be productive in, another project as priority and resources demand is critical. With this in mind we simply wouldn't be able move new projects to newer versions of Tapestry even if we could spend the ramp up time learning the new framework as we couldn't get everybody on the same page. Could you imagine being on a Tap4 project for several months, then moving to a Tap3 project for several more, and later getting onto a new project with the latest Tap5. Just keeping it all straight would drive the average person nuts. On 7/28/06, Jason Dyer <[EMAIL PROTECTED]> wrote: > > Because, a company that has invested a year or more, developing an app is > probably going to want to use it for a little while. Over the lifetime of > an > enterprise app, it will undoubtedly need modification (both bug fixes and > added features.) > > When Tapestry 5 arrives, we can safely assume that Tapestry 4 development > will > stop fairly shortly thereafter (new features immediately, maybe bug fixing > will go on for a year or two, but that's nothing compared to the lifetime > of > a large app.) Then there's the fact that, right now it's difficult enough > to > find people with skill in T4, but in a couple of years it'll be > impossible, > because most people will have moved on to T5... > > If the migration to T5 requires what basically amounts to a rewrite and T4 > is > no longer maintainable, then the 'powers that be' at said company are > going > to be a little irate that they've invested so much time/money into > something > that ultimately didn't last very long. In fact, they'll probably be > looking > for heads to roll... > > > On Friday 28 July 2006 18:48, adasal wrote: > > Seems I am wrong in my earlier post. > > Emm, but there is a lot of discussion around the need for compatibility. > > Why is it so desirable, it seems to posit a large ongoing project that > > spans both 4 and 5. Why would such a project need to hook up to 5? > > Adam > > > > -- > > -- > backups: always in season, never out of style. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Regards, Steven Bell -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: Tapestry 5 Discussions
That is one of the reasons. There are others. In my company we have many (possibly upwords of twenty) web projects going at any one time in various stages of development. The ability for a developer from one project to move to, and be productive in, another project as priority and resources demand is critical. With this in mind we simply wouldn't be able move new projects to newer versions of Tapestry even if we could spend the ramp up time learning the new framework as we couldn't get everybody on the same page. Could you imagine being on a Tap4 project for several months, then moving to a Tap3 project for several more, and later getting onto a new project with the latest Tap5. Just keeping it all straight would drive the average person nuts. On 7/28/06, Jason Dyer <[EMAIL PROTECTED]> wrote: Because, a company that has invested a year or more, developing an app is probably going to want to use it for a little while. Over the lifetime of an enterprise app, it will undoubtedly need modification (both bug fixes and added features.) When Tapestry 5 arrives, we can safely assume that Tapestry 4 development will stop fairly shortly thereafter (new features immediately, maybe bug fixing will go on for a year or two, but that's nothing compared to the lifetime of a large app.) Then there's the fact that, right now it's difficult enough to find people with skill in T4, but in a couple of years it'll be impossible, because most people will have moved on to T5... If the migration to T5 requires what basically amounts to a rewrite and T4 is no longer maintainable, then the 'powers that be' at said company are going to be a little irate that they've invested so much time/money into something that ultimately didn't last very long. In fact, they'll probably be looking for heads to roll... On Friday 28 July 2006 18:48, adasal wrote: > Seems I am wrong in my earlier post. > Emm, but there is a lot of discussion around the need for compatibility. > Why is it so desirable, it seems to posit a large ongoing project that > spans both 4 and 5. Why would such a project need to hook up to 5? > Adam > -- -- backups: always in season, never out of style. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Steven Bell
Re: Tapestry 5 Discussions
Because, a company that has invested a year or more, developing an app is probably going to want to use it for a little while. Over the lifetime of an enterprise app, it will undoubtedly need modification (both bug fixes and added features.) When Tapestry 5 arrives, we can safely assume that Tapestry 4 development will stop fairly shortly thereafter (new features immediately, maybe bug fixing will go on for a year or two, but that's nothing compared to the lifetime of a large app.) Then there's the fact that, right now it's difficult enough to find people with skill in T4, but in a couple of years it'll be impossible, because most people will have moved on to T5... If the migration to T5 requires what basically amounts to a rewrite and T4 is no longer maintainable, then the 'powers that be' at said company are going to be a little irate that they've invested so much time/money into something that ultimately didn't last very long. In fact, they'll probably be looking for heads to roll... On Friday 28 July 2006 18:48, adasal wrote: > Seems I am wrong in my earlier post. > Emm, but there is a lot of discussion around the need for compatibility. > Why is it so desirable, it seems to posit a large ongoing project that > spans both 4 and 5. Why would such a project need to hook up to 5? > Adam > -- -- backups: always in season, never out of style. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tapestry 5 Discussions
The argument against HiveMind is not against HiveMind, per se. It's about Tapestry adoption. Tapestry already has a battleground: the web framework space. By combining it with HM it now has two battles: web frameworks and IoC/lightweight-containers. While opting for its own built-in IoC container implies it has abandoned the entire "do one thing well" principle of most successful framework projects. The only technical argument for HiveMind is one of features. I think that's a call to extend Spring. Technically do-able and a win-win. I think the real decision about HiveMind may be ego. That is, we all tend to start identifying with the things we create and its hard not to. As to why Tap4->Tap5 is important, simply look at Tap3. It is less "supported" -- there's less active work in terms of enhancement, etc. going on in Tap3. Yesterday we didn't want Ajax. Today we do. Tap3 works for yesterday's apps but to add today's features Tap4 (4.1, in particular) is significantly superior. Tomorrow we'll likely face the same thing, something new only being supported in Tap5. So upgrade paths are important considerations when making an adoption decision. Thanks, Ezra Epstein -Original Message- From: adasal [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 3:49 PM To: Tapestry users Subject: Re: Tapestry 5 Discussions Seems I am wrong in my earlier post. Emm, but there is a lot of discussion around the need for compatibility. Why is it so desirable, it seems to posit a large ongoing project that spans both 4 and 5. Why would such a project need to hook up to 5? Adam On 28/07/06, Kris Rasmussen <[EMAIL PROTECTED]> wrote: > > I actually prefer hivemind to Spring. Just my 2 cents. I find it > easier to learn and better at what it does. > > Kris > > > - Original Message > From: Rui Pacheco <[EMAIL PROTECTED]> > To: Tapestry users > Sent: Friday, July 28, 2006 3:23:34 PM > Subject: Re: Tapestry 5 Discussions > > > Sometimes missing features is not a bad thing. If you want people to > use your framework, you need to implement something they can use. > Maybe losing some features and gaining some compatibility isn't such a > bad thing. The rest could come later. This is not a race. > > On 7/28/06, D&J Gredler <[EMAIL PROTECTED]> wrote: > > > > I completely agree with you, and I really wish Spring were up to the > task. > > However, Howard seems to have done his homework and come to the > conclusion > > that it can't provide the features he needs for Tap5 (see > > http://tapestry.apache.org/tapestry5/ioc/index.html). > > > > In my personal ideal world, Spring would have implemented the > namespacing, > > abstraction, visibility and distributed configuration features he > > needs, and we could all reuse our Spring knowledge when we find we > > need to extend Tap5. > > At this point all I can hope for is that they implement some of that > stuff > > in time for Tap6 :-) > > > > On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > > > > > Actually, I support the idea that leaving HiveMind is good. > > > But not for a new IoC container. We should be using something that > > > has more market share, like the Pico Container or the container > > > used by Spring. > > > Why are we writing a *new* IoC container? Why not standardise > Tapestry, > > > that > > > does something no other framework does, on components known > > > throughout > > the > > > developer community? > > > > > > Its all about reuse. Reuse components, reuse examples spread > > > through > the > > > web, reuse the knowledge you acquired on different projects. > > > > > > > > > > -- > Cumprimentos, > Rui Pacheco > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tapestry 5 Discussions
Seems I am wrong in my earlier post. Emm, but there is a lot of discussion around the need for compatibility. Why is it so desirable, it seems to posit a large ongoing project that spans both 4 and 5. Why would such a project need to hook up to 5? Adam On 28/07/06, Kris Rasmussen <[EMAIL PROTECTED]> wrote: I actually prefer hivemind to Spring. Just my 2 cents. I find it easier to learn and better at what it does. Kris - Original Message From: Rui Pacheco <[EMAIL PROTECTED]> To: Tapestry users Sent: Friday, July 28, 2006 3:23:34 PM Subject: Re: Tapestry 5 Discussions Sometimes missing features is not a bad thing. If you want people to use your framework, you need to implement something they can use. Maybe losing some features and gaining some compatibility isn't such a bad thing. The rest could come later. This is not a race. On 7/28/06, D&J Gredler <[EMAIL PROTECTED]> wrote: > > I completely agree with you, and I really wish Spring were up to the task. > However, Howard seems to have done his homework and come to the conclusion > that it can't provide the features he needs for Tap5 (see > http://tapestry.apache.org/tapestry5/ioc/index.html). > > In my personal ideal world, Spring would have implemented the namespacing, > abstraction, visibility and distributed configuration features he needs, > and > we could all reuse our Spring knowledge when we find we need to extend > Tap5. > At this point all I can hope for is that they implement some of that stuff > in time for Tap6 :-) > > On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > > > Actually, I support the idea that leaving HiveMind is good. > > But not for a new IoC container. We should be using something that has > > more > > market share, like the Pico Container or the container used by Spring. > > Why are we writing a *new* IoC container? Why not standardise Tapestry, > > that > > does something no other framework does, on components known throughout > the > > developer community? > > > > Its all about reuse. Reuse components, reuse examples spread through the > > web, reuse the knowledge you acquired on different projects. > > > > -- Cumprimentos, Rui Pacheco
Re: Tapestry 5 Discussions
I actually prefer hivemind to Spring. Just my 2 cents. I find it easier to learn and better at what it does. Kris - Original Message From: Rui Pacheco <[EMAIL PROTECTED]> To: Tapestry users Sent: Friday, July 28, 2006 3:23:34 PM Subject: Re: Tapestry 5 Discussions Sometimes missing features is not a bad thing. If you want people to use your framework, you need to implement something they can use. Maybe losing some features and gaining some compatibility isn't such a bad thing. The rest could come later. This is not a race. On 7/28/06, D&J Gredler <[EMAIL PROTECTED]> wrote: > > I completely agree with you, and I really wish Spring were up to the task. > However, Howard seems to have done his homework and come to the conclusion > that it can't provide the features he needs for Tap5 (see > http://tapestry.apache.org/tapestry5/ioc/index.html). > > In my personal ideal world, Spring would have implemented the namespacing, > abstraction, visibility and distributed configuration features he needs, > and > we could all reuse our Spring knowledge when we find we need to extend > Tap5. > At this point all I can hope for is that they implement some of that stuff > in time for Tap6 :-) > > On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > > > Actually, I support the idea that leaving HiveMind is good. > > But not for a new IoC container. We should be using something that has > > more > > market share, like the Pico Container or the container used by Spring. > > Why are we writing a *new* IoC container? Why not standardise Tapestry, > > that > > does something no other framework does, on components known throughout > the > > developer community? > > > > Its all about reuse. Reuse components, reuse examples spread through the > > web, reuse the knowledge you acquired on different projects. > > > > -- Cumprimentos, Rui Pacheco
Re: Tapestry 5 Discussions
Sometimes missing features is not a bad thing. If you want people to use your framework, you need to implement something they can use. Maybe losing some features and gaining some compatibility isn't such a bad thing. The rest could come later. This is not a race. On 7/28/06, D&J Gredler <[EMAIL PROTECTED]> wrote: I completely agree with you, and I really wish Spring were up to the task. However, Howard seems to have done his homework and come to the conclusion that it can't provide the features he needs for Tap5 (see http://tapestry.apache.org/tapestry5/ioc/index.html). In my personal ideal world, Spring would have implemented the namespacing, abstraction, visibility and distributed configuration features he needs, and we could all reuse our Spring knowledge when we find we need to extend Tap5. At this point all I can hope for is that they implement some of that stuff in time for Tap6 :-) On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > Actually, I support the idea that leaving HiveMind is good. > But not for a new IoC container. We should be using something that has > more > market share, like the Pico Container or the container used by Spring. > Why are we writing a *new* IoC container? Why not standardise Tapestry, > that > does something no other framework does, on components known throughout the > developer community? > > Its all about reuse. Reuse components, reuse examples spread through the > web, reuse the knowledge you acquired on different projects. > -- Cumprimentos, Rui Pacheco
Re: Tapestry 5 Discussions
I completely agree with you, and I really wish Spring were up to the task. However, Howard seems to have done his homework and come to the conclusion that it can't provide the features he needs for Tap5 (see http://tapestry.apache.org/tapestry5/ioc/index.html). In my personal ideal world, Spring would have implemented the namespacing, abstraction, visibility and distributed configuration features he needs, and we could all reuse our Spring knowledge when we find we need to extend Tap5. At this point all I can hope for is that they implement some of that stuff in time for Tap6 :-) On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: Actually, I support the idea that leaving HiveMind is good. But not for a new IoC container. We should be using something that has more market share, like the Pico Container or the container used by Spring. Why are we writing a *new* IoC container? Why not standardise Tapestry, that does something no other framework does, on components known throughout the developer community? Its all about reuse. Reuse components, reuse examples spread through the web, reuse the knowledge you acquired on different projects.
Re: Tapestry 5 Discussions
I'm sorry. I either I didn't word things clearly or you miss-understood me. It's not that we had to perform massive rework, it's that had we built any major applications in Tap 3 they would have required massive rework to bring them to Tap 4. We did build small demo/sample apps in the various technologies we were evaluating, usually covering about two pages and some basic operations. There was basically no straightforward upgrade path from Tap3 to Tap4. There was also some concern over the learning curve in Tapestry, but that wasn't a major issue (there is some learning curve for just about every framework) until it was combined with the shifting API. On 7/28/06, Payne, Matthew <[EMAIL PROTECTED]> wrote: How did the move from Tap3 to Tap4 require massive rework if you were still in evaluation? -Original Message- From: Steven Bell [mailto:[EMAIL PROTECTED] Sent: Fri 7/28/2006 4:30 PM To: Tapestry users Subject: Re: Tapestry 5 Discussions Picking through the name calling and attacks of the original message I find one legitimate point that hits very close to home. I work in a company that has (at a guess) 300+ Java developers (and we are moving all our other developers over to the Java language). Not long ago (While Tap4 was in early beta) we were evaluating several technologies for web development and Tap 3 was a strong contender. There were things we didn't like about it, but we didn't really find a better framework (this included Struts, JSF, Wicket, and others). As the evaluation went on and Tap 4 was getting closer to release it was also evaluated. The fact that the move from Tap 3 to Tap 4 required massive rework, and in some cases the way of doing thing was completely different, basically killed adoption. If changing versions requires relearning the framework large companies will not adopt Tapestry. I'm sorry, I think Tapestry is the best framework out there, but the investment is simply too large. P.S. That many developers and we are not a software company. On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > Actually, I support the idea that leaving HiveMind is good. > But not for a new IoC container. We should be using something that has > more > market share, like the Pico Container or the container used by Spring. > Why are we writing a *new* IoC container? Why not standardise Tapestry, > that > does something no other framework does, on components known throughout the > developer community? > > Its all about reuse. Reuse components, reuse examples spread through the > web, reuse the knowledge you acquired on different projects. > > If we want Tapestry to gain traction we must play our cards right, because > the market is hot. > > > On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > Yes really...That is pretty horribly inappropriate. > > > > Reading the spindle blog doesn't even give me the impression Geoff has > run > > off to make babies with GWT either. In fact, it looks like he just > > released > > a T4 compatible spindle plugin. > > > > Please keep your personal attacks for some other forum, like a private > > email > > or your own website. They aren't appropriate/wanted/appreciated here. > > > > thanks > > > > > > On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > > > > > ... And that's why Geoff Longman dropped off the boat to pursue > > something > > > more innovative (GWT) having a solid backing by a reputable company. > Not > > > with by a sole Saddam-like dictator like Howard. He pretends he's > > > democratic > > > by throwing his ideas under the umbrella "Discuss" but meanwhile he's > > made > > > up his mind already and won't thus listen to anyone. He didn't listen > to > > > Geoff that's why there's no Spindle for Tap 4. Now he claims on his > blog > > > that tooling is not important. Howard, maybe not to you, but let me > > > educate > > > you that there is a vast number of people out there who think > otherwise. > > > It's time you stop imposing your opinions on people. Remember, Wicket > > has > > > stolen a market share from Tapestry. Now there is GWT. Just wait until > > GWT > > > goes out of beta. I promiss you the following statements would hold in > > the > > > very near future: > > > > > > Tapestry = a+b; > > > Wicket = Tapestry - a; > > > GWT = Tapestry - b; > > > > > > Therefore Tapestry = 0. This would be the result by the time the > > > incompatible and crazy Tap 5.0 is released. And I would hand you a > &
RE: Tapestry 5 Discussions
+1 On replacing hivemind with spring. -Original Message- From: Rui Pacheco [mailto:[EMAIL PROTECTED] Sent: Fri 7/28/2006 3:58 PM To: Tapestry users Subject: Re: Tapestry 5 Discussions Actually, I support the idea that leaving HiveMind is good. But not for a new IoC container. We should be using something that has more market share, like the Pico Container or the container used by Spring. Why are we writing a *new* IoC container? Why not standardise Tapestry, that does something no other framework does, on components known throughout the developer community? Its all about reuse. Reuse components, reuse examples spread through the web, reuse the knowledge you acquired on different projects. If we want Tapestry to gain traction we must play our cards right, because the market is hot. On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Yes really...That is pretty horribly inappropriate. > > Reading the spindle blog doesn't even give me the impression Geoff has run > off to make babies with GWT either. In fact, it looks like he just > released > a T4 compatible spindle plugin. > > Please keep your personal attacks for some other forum, like a private > email > or your own website. They aren't appropriate/wanted/appreciated here. > > thanks > > > On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > > > ... And that's why Geoff Longman dropped off the boat to pursue > something > > more innovative (GWT) having a solid backing by a reputable company. Not > > with by a sole Saddam-like dictator like Howard. He pretends he's > > democratic > > by throwing his ideas under the umbrella "Discuss" but meanwhile he's > made > > up his mind already and won't thus listen to anyone. He didn't listen to > > Geoff that's why there's no Spindle for Tap 4. Now he claims on his blog > > that tooling is not important. Howard, maybe not to you, but let me > > educate > > you that there is a vast number of people out there who think otherwise. > > It's time you stop imposing your opinions on people. Remember, Wicket > has > > stolen a market share from Tapestry. Now there is GWT. Just wait until > GWT > > goes out of beta. I promiss you the following statements would hold in > the > > very near future: > > > > Tapestry = a+b; > > Wicket = Tapestry - a; > > GWT = Tapestry - b; > > > > Therefore Tapestry = 0. This would be the result by the time the > > incompatible and crazy Tap 5.0 is released. And I would hand you a > tissue > > paper to wipe off your hot tears. > > > > Regards, > > F > > > > > > On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > Howard, I know you're very innovative and all, but doesn't this really > > > sound > > > somewhat crazy to you? If you really want Tapestry to gain > acceptance, > > > then > > > backward compatibility is a big issue. I jumped into the Tapestry > world > > > with the 4.0 release and I'm really enjoying it, but if switching to > > 5.xis > > > going to be "VERY difficult", then I don't know if I'll ever upgrade. > > > Tapestry is definitely (IMHO) very superior to the "standard" JSF, but > > if > > > it > > > keeps becoming a "moving target", then it will never gain market > > > acceptance. > > > The big wigs will win out because they support a "standard." If > > Tapestry > > > has the reputation of becoming the "consultant's framework" (as has > been > > > said in the past) because it requires so much work to upgrade, then > it's > > > going to suffer. It's not that I disagree with the direction you're > > > heading. It's that I don't know whether or not changing paradigms so > > > drastically is a good idea for the health of the "product" or "brand." > > > > > > I agree so far with what you're doing. I don't like the fact that > > you're > > > switching from HiveMind to TapIoCa (that's my little nickname for the > > > Tapestry IoC container), but if you don't want to be tied to HiveMind > or > > > don't want to be constrained by the release schedule, then I > understand > > > (although you're a big part of the HiveMind community and we can > easily > > > accommodate any changes you could need IMHO). Anyway, this is your > > baby, > > > but if you want to gain some market share, then you
RE: Tapestry 5 Discussions
How did the move from Tap3 to Tap4 require massive rework if you were still in evaluation? -Original Message- From: Steven Bell [mailto:[EMAIL PROTECTED] Sent: Fri 7/28/2006 4:30 PM To: Tapestry users Subject: Re: Tapestry 5 Discussions Picking through the name calling and attacks of the original message I find one legitimate point that hits very close to home. I work in a company that has (at a guess) 300+ Java developers (and we are moving all our other developers over to the Java language). Not long ago (While Tap4 was in early beta) we were evaluating several technologies for web development and Tap 3 was a strong contender. There were things we didn't like about it, but we didn't really find a better framework (this included Struts, JSF, Wicket, and others). As the evaluation went on and Tap 4 was getting closer to release it was also evaluated. The fact that the move from Tap 3 to Tap 4 required massive rework, and in some cases the way of doing thing was completely different, basically killed adoption. If changing versions requires relearning the framework large companies will not adopt Tapestry. I'm sorry, I think Tapestry is the best framework out there, but the investment is simply too large. P.S. That many developers and we are not a software company. On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: > > Actually, I support the idea that leaving HiveMind is good. > But not for a new IoC container. We should be using something that has > more > market share, like the Pico Container or the container used by Spring. > Why are we writing a *new* IoC container? Why not standardise Tapestry, > that > does something no other framework does, on components known throughout the > developer community? > > Its all about reuse. Reuse components, reuse examples spread through the > web, reuse the knowledge you acquired on different projects. > > If we want Tapestry to gain traction we must play our cards right, because > the market is hot. > > > On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > Yes really...That is pretty horribly inappropriate. > > > > Reading the spindle blog doesn't even give me the impression Geoff has > run > > off to make babies with GWT either. In fact, it looks like he just > > released > > a T4 compatible spindle plugin. > > > > Please keep your personal attacks for some other forum, like a private > > email > > or your own website. They aren't appropriate/wanted/appreciated here. > > > > thanks > > > > > > On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > > > > > ... And that's why Geoff Longman dropped off the boat to pursue > > something > > > more innovative (GWT) having a solid backing by a reputable company. > Not > > > with by a sole Saddam-like dictator like Howard. He pretends he's > > > democratic > > > by throwing his ideas under the umbrella "Discuss" but meanwhile he's > > made > > > up his mind already and won't thus listen to anyone. He didn't listen > to > > > Geoff that's why there's no Spindle for Tap 4. Now he claims on his > blog > > > that tooling is not important. Howard, maybe not to you, but let me > > > educate > > > you that there is a vast number of people out there who think > otherwise. > > > It's time you stop imposing your opinions on people. Remember, Wicket > > has > > > stolen a market share from Tapestry. Now there is GWT. Just wait until > > GWT > > > goes out of beta. I promiss you the following statements would hold in > > the > > > very near future: > > > > > > Tapestry = a+b; > > > Wicket = Tapestry - a; > > > GWT = Tapestry - b; > > > > > > Therefore Tapestry = 0. This would be the result by the time the > > > incompatible and crazy Tap 5.0 is released. And I would hand you a > > tissue > > > paper to wipe off your hot tears. > > > > > > Regards, > > > F > > > > > > > > > On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > > > Howard, I know you're very innovative and all, but doesn't this > really > > > > sound > > > > somewhat crazy to you? If you really want Tapestry to gain > > acceptance, > > > > then > > > > backward compatibility is a big issue. I jumped into the Tapestry > > world > > > > with the 4.0 release and I'm really enjoying it, but if switching to > > > 5.xis > > > > going to be "V
Re: Tapestry 5 Discussions
#x27;s not that I disagree with the direction you're > > > heading. It's that I don't know whether or not changing paradigms so > > > drastically is a good idea for the health of the "product" or "brand." > > > > > > I agree so far with what you're doing. I don't like the fact that > > you're > > > switching from HiveMind to TapIoCa (that's my little nickname for the > > > Tapestry IoC container), but if you don't want to be tied to HiveMind > or > > > don't want to be constrained by the release schedule, then I > understand > > > (although you're a big part of the HiveMind community and we can > easily > > > accommodate any changes you could need IMHO). Anyway, this is your > > baby, > > > but if you want to gain some market share, then you should really > listen > > > to > > > your users. Tapestry is starting to get a bad reputation for not > > > supporting > > > backward compatibility. Again, I think the direction you're heading > is > > a > > > good one, if you don't have to consider your current users, but we > don't > > > have that luxury. > > > > > > > > > -Original Message- > > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > > > Sent: Friday, July 28, 2006 12:09 PM > > > To: Tapestry development > > > Subject: Re: Tapestry 5 Discussions > > > > > > Right now its impossible because there's nothing to convert to :-) > > > > > > It will be *VERY* difficult. This isn't a slap of new paint. Basic > > > paradigms are shifting around in a major way. It would be comparable, > > > or perhaps even larger than, converting between JSF and Tapestry 4. > > > Possibly on the order of converting from Struts to Tapestry 4. > > > > > > On 7/27/06, Norbert Sándor <[EMAIL PROTECTED]> wrote: > > > > I know that it's far away, but how easy/difficult will it be to > > convert > > > > an application from 4 to 5? > > > > > > > > Regards, > > > > Norbi > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > 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] > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > > -- Cumprimentos, Rui Pacheco -- Regards, Steven Bell
Re: Tapestry 5 Discussions
Sometimes , two good components do not fit together well to make one good combined application/component. Sad but true. Looking forward for tap5 ;) Alex On 7/28/06, Rui Pacheco <[EMAIL PROTECTED]> wrote: Actually, I support the idea that leaving HiveMind is good. But not for a new IoC container. We should be using something that has more market share, like the Pico Container or the container used by Spring. Why are we writing a *new* IoC container? Why not standardise Tapestry, that does something no other framework does, on components known throughout the developer community? Its all about reuse. Reuse components, reuse examples spread through the web, reuse the knowledge you acquired on different projects. If we want Tapestry to gain traction we must play our cards right, because the market is hot. On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Yes really...That is pretty horribly inappropriate. > > Reading the spindle blog doesn't even give me the impression Geoff has run > off to make babies with GWT either. In fact, it looks like he just > released > a T4 compatible spindle plugin. > > Please keep your personal attacks for some other forum, like a private > email > or your own website. They aren't appropriate/wanted/appreciated here. > > thanks > > > On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > > > ... And that's why Geoff Longman dropped off the boat to pursue > something > > more innovative (GWT) having a solid backing by a reputable company. Not > > with by a sole Saddam-like dictator like Howard. He pretends he's > > democratic > > by throwing his ideas under the umbrella "Discuss" but meanwhile he's > made > > up his mind already and won't thus listen to anyone. He didn't listen to > > Geoff that's why there's no Spindle for Tap 4. Now he claims on his blog > > that tooling is not important. Howard, maybe not to you, but let me > > educate > > you that there is a vast number of people out there who think otherwise. > > It's time you stop imposing your opinions on people. Remember, Wicket > has > > stolen a market share from Tapestry. Now there is GWT. Just wait until > GWT > > goes out of beta. I promiss you the following statements would hold in > the > > very near future: > > > > Tapestry = a+b; > > Wicket = Tapestry - a; > > GWT = Tapestry - b; > > > > Therefore Tapestry = 0. This would be the result by the time the > > incompatible and crazy Tap 5.0 is released. And I would hand you a > tissue > > paper to wipe off your hot tears. > > > > Regards, > > F > > > > > > On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > Howard, I know you're very innovative and all, but doesn't this really > > > sound > > > somewhat crazy to you? If you really want Tapestry to gain > acceptance, > > > then > > > backward compatibility is a big issue. I jumped into the Tapestry > world > > > with the 4.0 release and I'm really enjoying it, but if switching to > > 5.xis > > > going to be "VERY difficult", then I don't know if I'll ever upgrade. > > > Tapestry is definitely (IMHO) very superior to the "standard" JSF, but > > if > > > it > > > keeps becoming a "moving target", then it will never gain market > > > acceptance. > > > The big wigs will win out because they support a "standard." If > > Tapestry > > > has the reputation of becoming the "consultant's framework" (as has > been > > > said in the past) because it requires so much work to upgrade, then > it's > > > going to suffer. It's not that I disagree with the direction you're > > > heading. It's that I don't know whether or not changing paradigms so > > > drastically is a good idea for the health of the "product" or "brand." > > > > > > I agree so far with what you're doing. I don't like the fact that > > you're > > > switching from HiveMind to TapIoCa (that's my little nickname for the > > > Tapestry IoC container), but if you don't want to be tied to HiveMind > or > > > don't want to be constrained by the release schedule, then I > understand > > > (although you're a big part of the HiveMind community and we can > easily > > > accommodate any changes you could need IMHO). Anyway, this is your > > baby, > > > but if you want to gain some marke
Re: Tapestry 5 Discussions
Actually, I support the idea that leaving HiveMind is good. But not for a new IoC container. We should be using something that has more market share, like the Pico Container or the container used by Spring. Why are we writing a *new* IoC container? Why not standardise Tapestry, that does something no other framework does, on components known throughout the developer community? Its all about reuse. Reuse components, reuse examples spread through the web, reuse the knowledge you acquired on different projects. If we want Tapestry to gain traction we must play our cards right, because the market is hot. On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Yes really...That is pretty horribly inappropriate. Reading the spindle blog doesn't even give me the impression Geoff has run off to make babies with GWT either. In fact, it looks like he just released a T4 compatible spindle plugin. Please keep your personal attacks for some other forum, like a private email or your own website. They aren't appropriate/wanted/appreciated here. thanks On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: > > ... And that's why Geoff Longman dropped off the boat to pursue something > more innovative (GWT) having a solid backing by a reputable company. Not > with by a sole Saddam-like dictator like Howard. He pretends he's > democratic > by throwing his ideas under the umbrella "Discuss" but meanwhile he's made > up his mind already and won't thus listen to anyone. He didn't listen to > Geoff that's why there's no Spindle for Tap 4. Now he claims on his blog > that tooling is not important. Howard, maybe not to you, but let me > educate > you that there is a vast number of people out there who think otherwise. > It's time you stop imposing your opinions on people. Remember, Wicket has > stolen a market share from Tapestry. Now there is GWT. Just wait until GWT > goes out of beta. I promiss you the following statements would hold in the > very near future: > > Tapestry = a+b; > Wicket = Tapestry - a; > GWT = Tapestry - b; > > Therefore Tapestry = 0. This would be the result by the time the > incompatible and crazy Tap 5.0 is released. And I would hand you a tissue > paper to wipe off your hot tears. > > Regards, > F > > > On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > Howard, I know you're very innovative and all, but doesn't this really > > sound > > somewhat crazy to you? If you really want Tapestry to gain acceptance, > > then > > backward compatibility is a big issue. I jumped into the Tapestry world > > with the 4.0 release and I'm really enjoying it, but if switching to > 5.xis > > going to be "VERY difficult", then I don't know if I'll ever upgrade. > > Tapestry is definitely (IMHO) very superior to the "standard" JSF, but > if > > it > > keeps becoming a "moving target", then it will never gain market > > acceptance. > > The big wigs will win out because they support a "standard." If > Tapestry > > has the reputation of becoming the "consultant's framework" (as has been > > said in the past) because it requires so much work to upgrade, then it's > > going to suffer. It's not that I disagree with the direction you're > > heading. It's that I don't know whether or not changing paradigms so > > drastically is a good idea for the health of the "product" or "brand." > > > > I agree so far with what you're doing. I don't like the fact that > you're > > switching from HiveMind to TapIoCa (that's my little nickname for the > > Tapestry IoC container), but if you don't want to be tied to HiveMind or > > don't want to be constrained by the release schedule, then I understand > > (although you're a big part of the HiveMind community and we can easily > > accommodate any changes you could need IMHO). Anyway, this is your > baby, > > but if you want to gain some market share, then you should really listen > > to > > your users. Tapestry is starting to get a bad reputation for not > > supporting > > backward compatibility. Again, I think the direction you're heading is > a > > good one, if you don't have to consider your current users, but we don't > > have that luxury. > > > > > > -Original Message- > > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 28, 2006 12:09 PM > > To: Tapestry development > > Subject: Re: Tap
Re: Tapestry 5 Discussions
Yes really...That is pretty horribly inappropriate. Reading the spindle blog doesn't even give me the impression Geoff has run off to make babies with GWT either. In fact, it looks like he just released a T4 compatible spindle plugin. Please keep your personal attacks for some other forum, like a private email or your own website. They aren't appropriate/wanted/appreciated here. thanks On 7/28/06, Francis Amanfo <[EMAIL PROTECTED]> wrote: ... And that's why Geoff Longman dropped off the boat to pursue something more innovative (GWT) having a solid backing by a reputable company. Not with by a sole Saddam-like dictator like Howard. He pretends he's democratic by throwing his ideas under the umbrella "Discuss" but meanwhile he's made up his mind already and won't thus listen to anyone. He didn't listen to Geoff that's why there's no Spindle for Tap 4. Now he claims on his blog that tooling is not important. Howard, maybe not to you, but let me educate you that there is a vast number of people out there who think otherwise. It's time you stop imposing your opinions on people. Remember, Wicket has stolen a market share from Tapestry. Now there is GWT. Just wait until GWT goes out of beta. I promiss you the following statements would hold in the very near future: Tapestry = a+b; Wicket = Tapestry - a; GWT = Tapestry - b; Therefore Tapestry = 0. This would be the result by the time the incompatible and crazy Tap 5.0 is released. And I would hand you a tissue paper to wipe off your hot tears. Regards, F On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: > > Howard, I know you're very innovative and all, but doesn't this really > sound > somewhat crazy to you? If you really want Tapestry to gain acceptance, > then > backward compatibility is a big issue. I jumped into the Tapestry world > with the 4.0 release and I'm really enjoying it, but if switching to 5.xis > going to be "VERY difficult", then I don't know if I'll ever upgrade. > Tapestry is definitely (IMHO) very superior to the "standard" JSF, but if > it > keeps becoming a "moving target", then it will never gain market > acceptance. > The big wigs will win out because they support a "standard." If Tapestry > has the reputation of becoming the "consultant's framework" (as has been > said in the past) because it requires so much work to upgrade, then it's > going to suffer. It's not that I disagree with the direction you're > heading. It's that I don't know whether or not changing paradigms so > drastically is a good idea for the health of the "product" or "brand." > > I agree so far with what you're doing. I don't like the fact that you're > switching from HiveMind to TapIoCa (that's my little nickname for the > Tapestry IoC container), but if you don't want to be tied to HiveMind or > don't want to be constrained by the release schedule, then I understand > (although you're a big part of the HiveMind community and we can easily > accommodate any changes you could need IMHO). Anyway, this is your baby, > but if you want to gain some market share, then you should really listen > to > your users. Tapestry is starting to get a bad reputation for not > supporting > backward compatibility. Again, I think the direction you're heading is a > good one, if you don't have to consider your current users, but we don't > have that luxury. > > > -Original Message- > From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] > Sent: Friday, July 28, 2006 12:09 PM > To: Tapestry development > Subject: Re: Tapestry 5 Discussions > > Right now its impossible because there's nothing to convert to :-) > > It will be *VERY* difficult. This isn't a slap of new paint. Basic > paradigms are shifting around in a major way. It would be comparable, > or perhaps even larger than, converting between JSF and Tapestry 4. > Possibly on the order of converting from Struts to Tapestry 4. > > On 7/27/06, Norbert Sándor <[EMAIL PROTECTED]> wrote: > > I know that it's far away, but how easy/difficult will it be to convert > > an application from 4 to 5? > > > > Regards, > > Norbi > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > 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,
Re: Tapestry 5 Discussions
... And that's why Geoff Longman dropped off the boat to pursue something more innovative (GWT) having a solid backing by a reputable company. Not with by a sole Saddam-like dictator like Howard. He pretends he's democratic by throwing his ideas under the umbrella "Discuss" but meanwhile he's made up his mind already and won't thus listen to anyone. He didn't listen to Geoff that's why there's no Spindle for Tap 4. Now he claims on his blog that tooling is not important. Howard, maybe not to you, but let me educate you that there is a vast number of people out there who think otherwise. It's time you stop imposing your opinions on people. Remember, Wicket has stolen a market share from Tapestry. Now there is GWT. Just wait until GWT goes out of beta. I promiss you the following statements would hold in the very near future: Tapestry = a+b; Wicket = Tapestry - a; GWT = Tapestry - b; Therefore Tapestry = 0. This would be the result by the time the incompatible and crazy Tap 5.0 is released. And I would hand you a tissue paper to wipe off your hot tears. Regards, F On 7/28/06, James Carman <[EMAIL PROTECTED]> wrote: Howard, I know you're very innovative and all, but doesn't this really sound somewhat crazy to you? If you really want Tapestry to gain acceptance, then backward compatibility is a big issue. I jumped into the Tapestry world with the 4.0 release and I'm really enjoying it, but if switching to 5.xis going to be "VERY difficult", then I don't know if I'll ever upgrade. Tapestry is definitely (IMHO) very superior to the "standard" JSF, but if it keeps becoming a "moving target", then it will never gain market acceptance. The big wigs will win out because they support a "standard." If Tapestry has the reputation of becoming the "consultant's framework" (as has been said in the past) because it requires so much work to upgrade, then it's going to suffer. It's not that I disagree with the direction you're heading. It's that I don't know whether or not changing paradigms so drastically is a good idea for the health of the "product" or "brand." I agree so far with what you're doing. I don't like the fact that you're switching from HiveMind to TapIoCa (that's my little nickname for the Tapestry IoC container), but if you don't want to be tied to HiveMind or don't want to be constrained by the release schedule, then I understand (although you're a big part of the HiveMind community and we can easily accommodate any changes you could need IMHO). Anyway, this is your baby, but if you want to gain some market share, then you should really listen to your users. Tapestry is starting to get a bad reputation for not supporting backward compatibility. Again, I think the direction you're heading is a good one, if you don't have to consider your current users, but we don't have that luxury. -Original Message- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 12:09 PM To: Tapestry development Subject: Re: Tapestry 5 Discussions Right now its impossible because there's nothing to convert to :-) It will be *VERY* difficult. This isn't a slap of new paint. Basic paradigms are shifting around in a major way. It would be comparable, or perhaps even larger than, converting between JSF and Tapestry 4. Possibly on the order of converting from Struts to Tapestry 4. On 7/27/06, Norbert Sándor <[EMAIL PROTECTED]> wrote: > I know that it's far away, but how easy/difficult will it be to convert > an application from 4 to 5? > > Regards, > Norbi > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
