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 > > 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 > >
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 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, > > >
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 "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
RE: Streaming files from Tapestry
If the content is available from another servlet context then hasn't this added (only) more obscurity rather than security? It seems for the security the servlet must do the authorization check before serving hence, again, I don't see how it relates to Tapestry. Thanks, Ezra Epstein -Original Message- From: Murray Collingwood [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 2:14 PM To: Tapestry users Subject: RE: Streaming files from Tapestry Hi Ezra I did look at doing this as a work around, however it has one major flaw - it doesn't provide any security. In a CRM system, for example, if the document download link is http://webserver/MyOtherWebContext/images/01.doc then it's not going to take somebody long to realise they can type in other numbers and retrieve documents that they may not have access to. With a servlet running inside my application I can check the users security immediately before I stream the document. The other benefit of keeping the servlet as part of my application is that I can store the external directory name in one location rather than two. A small benefit. My final argument is that the faq should be providing the recommended solution. Obviously lots of people have already asked for this (that's why it's in a faq) so I'm not alone out here... I have written a small servlet to do what I want. It has limited functionality but it serves my immediate purpose. I am still hopeful that somebody will deliver a servlet or library that does serve this purpose in a better and generic method, I am happy to be the first to test and implement it. Cheers mc On 28 Jul 2006 at 9:53, Epstein, Ezra wrote: > I'm not sure I really followed, but your option "c" doesn't seem to have > anything to do with a web framework (tapestry or otherwise). Rather you're > just dynamically generating some text a la: > > > > Or whatever. The only part of that which is dynamic is the image name. And > "Any" tag can give you this no sweat. Maybe the name of the other web > context is a config param and so is "dynamic" too. Again, no sweat. > > As for the serving of the static files themselves (the name of a given file > is "dynamic" in that if you're showing the details of a CD then the image > name may depend on the product, but the image itself is in a web servers file > system) any web server will do. Apache, Tomcat, JBoss, etc. I think the > problem is with the word "stream". Stream implies dynamically feeding data > into the response. I think your question is about serving images. If so, > it's a snap. For example, I serve my "Tapestry" javascript files (same > applies to images) simply as: > > src="/MyTapestryAppName/js/myJavaScriptFile.js"> > > Works great. > > Perhaps I misread the question. > > Thanks, > > Ezra Epstein > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/402 - Release Date: 27/07/2006 - 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: Streaming files from Tapestry
Hi Ezra I did look at doing this as a work around, however it has one major flaw - it doesn't provide any security. In a CRM system, for example, if the document download link is http://webserver/MyOtherWebContext/images/01.doc then it's not going to take somebody long to realise they can type in other numbers and retrieve documents that they may not have access to. With a servlet running inside my application I can check the users security immediately before I stream the document. The other benefit of keeping the servlet as part of my application is that I can store the external directory name in one location rather than two. A small benefit. My final argument is that the faq should be providing the recommended solution. Obviously lots of people have already asked for this (that's why it's in a faq) so I'm not alone out here... I have written a small servlet to do what I want. It has limited functionality but it serves my immediate purpose. I am still hopeful that somebody will deliver a servlet or library that does serve this purpose in a better and generic method, I am happy to be the first to test and implement it. Cheers mc On 28 Jul 2006 at 9:53, Epstein, Ezra wrote: > I'm not sure I really followed, but your option "c" doesn't seem to have > anything to do with a web framework (tapestry or otherwise). Rather you're > just dynamically generating some text a la: > > > > Or whatever. The only part of that which is dynamic is the image name. And > "Any" tag can give you this no sweat. Maybe the name of the other web > context is a config param and so is "dynamic" too. Again, no sweat. > > As for the serving of the static files themselves (the name of a given file > is "dynamic" in that if you're showing the details of a CD then the image > name may depend on the product, but the image itself is in a web servers file > system) any web server will do. Apache, Tomcat, JBoss, etc. I think the > problem is with the word "stream". Stream implies dynamically feeding data > into the response. I think your question is about serving images. If so, > it's a snap. For example, I serve my "Tapestry" javascript files (same > applies to images) simply as: > > src="/MyTapestryAppName/js/myJavaScriptFile.js"> > > Works great. > > Perhaps I misread the question. > > Thanks, > > Ezra Epstein > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/402 - Release Date: 27/07/2006 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 "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
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 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 compar
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: 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 > > > > > > -
How to pass a parameter to an ASO constructor?
Hi all, I'm trying to figure out how to pass a constructor argument when constructing an ASO. I have a java.lang.Boolean, and it *needs* to have a parameter passed in the constructor (no empty-arg constructor exists). I know this ought to be simple, but I don't see any documentation explaining the proper way to do this. This current way doesn't work: false Any hints would be greatly appreciated. Thanks, Danny - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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, 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 wor
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]
RE: bug PageSpecificationResolverImpl does not find Implicit page specfications in all the correct places
Summary
"Implicit"(lacking page specification) pages (.html files) are only looked for
/{webroot}
e.g.
// looks in web root
Resource templateResource =
getContextRoot().getRelativeResource(templateName);
if (_log.isDebugEnabled())
_log.debug(ResolverMessages.checkingResource(templateResource));
if (templateResource.getResourceURL() != null)
{
setupImplicitPage(templateResource, namespaceLocation);
return;
}
After that, it should look do(doesn't do this now) -->
// {webroot}/WEB-INF/{app-name}/{templateName}
templateResource =
getWebInfAppLocation().getRelativeResource(templateName);
if (templateResource.getResourceURL() != null)
{
setupImplicitPage(templateResource, namespaceLocation);
return;
}
Matt
-Original Message-
From: Payne, Matthew [mailto:[EMAIL PROTECTED]
Sent: Friday, July 28, 2006 1:52 PM
To: users@tapestry.apache.org
Subject:fyi: bug PageSpecificationResolverImpl does not find Implicit
page specfications in all the correct places
https://issues.apache.org/jira/browse/TAPESTRY-1026
Summary
Page specifications are supposed to be optional. However, the
PageSpecificationResolverImpl does not find templates in all the same
places/paths that is searches for actual .page specifications.
java class for page -->
com.pennmutual.csc.pages.admin.ManageUsers
My .application file
[code]
http://jakarta.apache.org/tapestry/dtd/Tapestry_4_0.dtd";>
[/code]
e.g. default package is. com.pennmutual.csc.pages
root templates/specs are in /WEB-INF/csc
The url of the page that is not found is
http://localhost:8080/cee/admin/ManageUsers.html
If I put a page/specification file in /WEB-INF/csc/admin the page is found
(Correct)
If I delete that page specification and just put my template in
{webroot}/admin/, page specification is implicitly created (Correct).
***If I put my template in {webroot}/WEB-INF/csc/admin with no .page
specification, the template is not found and no "implicit" specfication is
create (InCorrect).**
This message, including any attachments, is intended only for the recipient(s)
named above. It may contain confidential and privileged information. If you
have
received this communication in error, please notify the sender immediately and
destroy or delete the original message. Also, please be aware that if you are
not
the intended recipient, any review, disclosure, copying, distribution or any
action or reliance based on this message is prohibited by law.
This message, including any attachments, is intended only for the recipient(s)
named above. It may contain confidential and privileged information. If you
have
received this communication in error, please notify the sender immediately and
destroy or delete the original message. Also, please be aware that if you are
not
the intended recipient, any review, disclosure, copying, distribution or any
action or reliance based on this message is prohibited by law.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Portlet Examples
Yes, there are several. One hosted by Howard, I believe, that is pre-config'd to run under JetSpeed or eXo. Then there's a very simple one here: http://labs.jboss.com/portal/portletswap/downloads/portlets/framework Thanks, Ezra Epstein -Original Message- From: Joel Trunick [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 9:11 AM To: Tapestry users Subject: Portlet Examples I have not seen any samples of Tapestry portlets on the web, there is a hello world one described on this forum, but it would be nice to have code samples. Anyone know of any? Joel - 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]
fyi: bug PageSpecificationResolverImpl does not find Implicit page specfications in all the correct places
https://issues.apache.org/jira/browse/TAPESTRY-1026
Summary
Page specifications are supposed to be optional. However, the
PageSpecificationResolverImpl does not find templates in all the same
places/paths that is searches for actual .page specifications.
java class for page -->
com.pennmutual.csc.pages.admin.ManageUsers
My .application file
[code]
http://jakarta.apache.org/tapestry/dtd/Tapestry_4_0.dtd";>
[/code]
e.g. default package is. com.pennmutual.csc.pages
root templates/specs are in /WEB-INF/csc
The url of the page that is not found is
http://localhost:8080/cee/admin/ManageUsers.html
If I put a page/specification file in /WEB-INF/csc/admin the page is found
(Correct)
If I delete that page specification and just put my template in
{webroot}/admin/, page specification is implicitly created (Correct).
***If I put my template in {webroot}/WEB-INF/csc/admin with no .page
specification, the template is not found and no "implicit" specfication is
create (InCorrect).**
This message, including any attachments, is intended only for the recipient(s)
named above. It may contain confidential and privileged information. If you
have
received this communication in error, please notify the sender immediately and
destroy or delete the original message. Also, please be aware that if you are
not
the intended recipient, any review, disclosure, copying, distribution or any
action or reliance based on this message is prohibited by law.
Re: Tap 4.1 / doc
Someone pointed me to this site for the jars: http://people.apache.org/repo/m2-snapshot-repository/org/apache/tapestry/ I replaced the 4.0 jars with 4.1 on a current project and everything seems to work perfectly. What I find curious is that the framework jar is 2.1MBinstead of 1.something for 4.0 I am also curious for documentation. I don't have much experience with Ajax, I don't know how I am suppose to build the flow of the application, so I am eagerly waiting for the documentation too. On 7/28/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote: Hi, yesterday i read on the list that Tap4.1 seems ot be out today (as beta), and since im starting a new project, i thought i may try it with 4.1 oinstead of 4.0. So i went to webpage and it also found some info (but no beta - jars so far).So, will it be out as beta in usable jar files or not ? And another question: does the Tap4.1 doc who is online also exist as a PDF or sth like that? - I know that im oldfashioned, but i prefer it to print everything out and then read it Best Regards, Korbinian -- Cumprimentos, Rui Pacheco
Tap 4.1 / doc
Hi, yesterday i read on the list that Tap4.1 seems ot be out today (as beta), and since im starting a new project, i thought i may try it with 4.1 oinstead of 4.0. So i went to webpage and it also found some info (but no beta - jars so far).So, will it be out as beta in usable jar files or not ? And another question: does the Tap4.1 doc who is online also exist as a PDF or sth like that? - I know that im oldfashioned, but i prefer it to print everything out and then read it Best Regards, Korbinian
RE: Streaming files from Tapestry
I'm not sure I really followed, but your option "c" doesn't seem to have anything to do with a web framework (tapestry or otherwise). Rather you're just dynamically generating some text a la: Or whatever. The only part of that which is dynamic is the image name. And "Any" tag can give you this no sweat. Maybe the name of the other web context is a config param and so is "dynamic" too. Again, no sweat. As for the serving of the static files themselves (the name of a given file is "dynamic" in that if you're showing the details of a CD then the image name may depend on the product, but the image itself is in a web servers file system) any web server will do. Apache, Tomcat, JBoss, etc. I think the problem is with the word "stream". Stream implies dynamically feeding data into the response. I think your question is about serving images. If so, it's a snap. For example, I serve my "Tapestry" javascript files (same applies to images) simply as: Works great. Perhaps I misread the question. Thanks, Ezra Epstein -Original Message- From: Murray Collingwood [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 5:35 AM To: Tapestry users Subject: RE: Streaming files from Tapestry Hi all :THIS SOUNDS SIMPLE Thanks for the response detlef but I'm still short of a simple example. How complicated can it be to deliver binary files (such as images) from a webserver to a webclient? Why is it that I need to write my own engine service That sounds complicated and the mere fact that nobody else seems willing to provide the documentation to do this only serves to confirm my suspicion that it is complicated! Okay, so writing an engine service is complicated and nobody wants to document it. Instead I'm being asked to download an example application and then work out how the example works, to identify the required bits of code to do what I need and be able to copy and implement these in my application. :DOESN'T EVERYBODY NEED ONE OF THESE All of this despite the generic requirement that many web applications would have for storing and retrieving documents (images / blobs / etc). :SAMPLE CONFIGURATION SUGGESTION I realise this is an open source project so I would like to volunteer the configuration component necessary: servesBinaryFiles org.somebody.SimpleBinaryServlet 0 binaryPath /home/application/storage servesBinaryFiles /extimage/* All we need now is somebody who knows how to write the SimpleBinaryServlet to do so. Can we then add it into Tapestry and then we would have a solution that everybody could use. :HAVE I GOT IT ALL WRONG? Perhaps I've missed something? Is this too easy? If so then it won't take somebody very long to do, however as above, I'm still thinking along the lines that it's not that simple. Perhaps I've got it right? Is writing an engine service difficult? If so then how can our average web developer with a year or two of Tapestry experience be expected to do this? :MORE BACKGROUND ON WHAT THIS IS ALL ABOUT And finally, just so that everybody understands the application. Consider for example an online shop, we upload an image of a product. We can store that image (and perhaps a thumbnail variation) in one of three places: a) In the database as a BLOB (although a number of databases I have tried experience performance issues dealing with blobs) b) In a directory within my webapp root (this is a very dangerous location, if you undeploy an application it will delete everything under the webapp root - I've had this happen and it's not nice) Also, by definition the webapp root is simply an expansion of the war/ear, to store dynamic files in this location goes against that standard. Potentially an administrator should be able to delete the webapp subdirectories and they should rebuild by expansion of the war/ear files. c) In a directory external to my webapp root. Outside of my webapp root I'm not going to have any problems redeploying my application. Also, I can backup the data (the database and the external binary directory) separately from the programs - this is a good thing. And finally this method requires that I access each file via a program that can potentially check security settings before letting me view the file - this would be a requirement for any CRM style of system. If you don't have dynamic binary files (eg images associated with database records etc) then you can store static images in your war file, no problem. If your website only requires dynamic text (eg stored in a database) then you won't need any binary file management, again no problem. If you do require dynamic binary files then options (a) and (b) are not great, leaving only option (c). My hunch is that this is a common requirement of many web applications, certainly it has been of the sites I have developed over the years. :THE FINAL SUMMARY / SOLUTION My ideal
Re: include an external script in a .script file
Ah nevermind. I was thinking you wanted to load it in via XHR for some reason. If you have a static url for the resource then just include it as you just did. Or make it a parameter that you pass in to the template. The script-include element is meant for including context/classpath relative resources. On 7/28/06, Henri Dupre <[EMAIL PROTECTED]> wrote: So you mean https://www.website.com/tracker.js "> Wouldn't work? I'm 90% positive that this is working currently somehow with most browsers. This is something one of our partner is asking us to use and I'd be quite surprised it is not working. I did a little search on cross-domain scripting, there seem to be limitations on what information cross domain javascript can use but I did not find any reference that would say this is completly bloked... Do you have any source Jesse? And how could I implement this on tapestry (sorry for my ignorance on Javascript)? Henri. On 7/28/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Even if it did allow you to do that no browser would allow it. You can't > load scripts across domains by default. > > You can of course do it when using dojo though ;) > > http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book48 > > On 7/28/06, Henri Dupre <[EMAIL PROTECTED]> wrote: > > > > I want to have a component that will add an include for a javascript to > an > > external website and also that will do some initialization for this > > script. > > I tried with a .script component and I put the following stuff: > > > > > >https://.../script.js"/> > > But this generates > >