Hello Howard, Actually, security was only an exemple. And because, i am pretty new to spring-security and to be honest, not really convinced at the moment, i will not try to defend it.
But my question was : What about the Integration of Tapestry in other Framework ? Because many people talked about integration technologies into Tapestry which is IMHO pretty cool, for server side technology and even client side. I was thinking of this question maybe because of some frustration, i admit :) but i think that opening API to other technologies contributes to make a framework popular as much as the inverse. However, let's continue with security exemple. Let's imagine that tomorrow, we expose some of our features with a technology like DWR, or some REST API or anything that goes though HTTP : Will i have to : 1. Re-implement security into those technologies 2. Create some extension to my existing spring-security 3. Implement DWR or REST API into Tapestry, implement a new Dispatcher, an then extend my own security implementation to handle security for this new type of Request - The first solution is the worst i should do :) - The second sounds reasonable to me from an architecture point of view, i keep security layer independant from underlying technologies and in front of all my services - The third make me consider Tapestry as an application container, and not only a Web Framework. To be honest, the third is maybe the more interesting from my developer point of view, because like many, i like to do it myself. But i have learned with my professional experience that re-invent the wheel is rarely the best approach. This is the reason why i am investigating into other technologies to achieve my goals. I don't think this is so bad... even for simple things like securing access to pages. Also, i don't think that analyzing Tapestry URLs from the outside is so rare, it is actually used deep into the pipeline (Dispatcher) but does not require so many parameters : is see request path and request locale... My objective is not to criticize because i am convinced 100% by Tapestry, but simply to open the discussion instead of focusing on existing contribution in Tapestry. Which, i repeat is not so complicated once you get familiar with Tapestry Architecture. Best Regards, Christophe. 2009/12/24 Howard Lewis Ship <hls...@gmail.com> > On Thu, Dec 24, 2009 at 2:09 AM, cordenier christophe > <christophe.corden...@gmail.com> wrote: > > Hello, > > > > And what about integration of Tapestry in other framework ? > > > > From my experience view, integrating technologies in Tapestry is fun and > > fast, and the one provided by Tapestry are really good and enough to do > what > > a Web Application should do. !but when i want to do the inverse i am > facing > > a problem with Tapestry public API. Getting the Tapestry registry is > simple > > but calling services from the outside is not as easy. > > > > For exemple, currently i am trying to secure my application by using > > spring-security to centralize security concerns, and then create a > RoleVoter > > to secure also Tapestry URLs. To achieve this, Spring allows me to access > to > > the servlet context and then to Tapestry Registry, now we can imagine > that > > analyzing the URL will be as easy as using the ComponentEventLinkEncoder > > service, but in real i had to create an instance of RequestImpl, retrieve > > others services, set the request into the RequestGlobals... service just > to > > analyze the URL ! > > I can see where your frustration might come from in this respect. At > many times during the > development of Tapestry, we've had to make a choice: easy and > automatic for the typical user, > or easily extensible for the power-developer. That's a no-brainer: > easy and automatic for the typical user is the way to go. > > In this particular case, it was all about making things work correctly > from inside Tapestry; the idea > that you would be "analyzing" a Tapestry URL when not in the middle of > processing a Tapestry request (and therefore, deep > into the pipeline that automatically sets up the RequestGlobals > values) is just foreign to Tapestry. That is, to make > that rare use-case easier for you, would complicate the code for most > other users, making it that much harder to extend and > override Tapestry for more typical use cases. > > In fact, where other people might write servlets, I would tend to > contribute a new Dispatcher to the MasterDispatcher > service to accomplish the same goal (in the rare case that existing > Dispatchers and other Tapestry mechanisms could not > fulfill the required role). > > I'm also a bit surprised at how eager people are to make use of > cumbersome solutions like Spring Security to accomplish simple tasks > such > as protecting pages. The Spring Security logic is path-based, > requiring an awkward mapping from paths to Tapestry pages. When I > need to implement that > kind of security, I define annotations that I can place on pages and > provide a filter that checks for the annotation on the page ... and > I've seen multiple clients > do the same thing. Ideally there would be a single solution for this, > but I've found that page security is just not a one-size-fits-all > solution. > > In other words, jumping over backwards for integrations with > technologies is often not the best approach. Yes, it would be nice to > have a checkbox "compatible with Spring Security" but I'd rather talk > about how easy it is to create your own custom extensions that work > precisely as you need. > > We've had this discussion at Formos; it was often easier to create a > totally custom solution in Tapestry than it was to take an > off-the-shelf solution that did 80% of what was needed and customize > it the last 20% of the way. > > > > > Tapestry is so powerful and has everything to work standalone (see > wrappers > > around servlet API, or PageTester, ...), but sometimes it's hard to > exploit > > this great feature ... > > > > Best Regards, > > Christophe > > > > > > > > 2009/12/23 Howard Lewis Ship <hls...@gmail.com> > > > >> While it's true that other frameworks (Grails, Wicket, Rails) have > >> large numbers of integrations, if you talk to real developers you find > >> out that the majority of those integrations are not actually usable > >> for production work. All too often, they are orphaned, unsupported, > >> incomplete, naive or coded against an earlier version of the core > >> framework ... or some combination of all of those. > >> > >> I do a lot of training and consulting on Tapestry with a lot of groups > >> and what I find is that one size does not fit all, even for simple > >> things like user authentication/login. I'm quite happy to have a > >> limited number of basic integrations that are documented, supported > >> and tested. Would I like every application to just be a matter of > >> mixing pre-built modules together? Yes. Do I think it is realistic, > >> for ANY framework? No. > >> > >> On Wed, Dec 23, 2009 at 7:48 AM, Howard Lewis Ship <hls...@gmail.com> > >> wrote: > >> > Noe, I've been down this path before, regrettably. The ONLY thing to > >> > do it to ignore the trolls. > >> > > >> > On Tue, Dec 22, 2009 at 11:29 PM, Newham, Cameron < > cameron.new...@bl.uk> > >> wrote: > >> >> I don't agree with the OP that the ServerSide discussion shows > Tapestry > >> "has lost the battle" - two posters state they don't want to see > Tapestry > >> mentioned. That's all there is. > >> >> > >> >> However, I can't agree with you Thiago. The old saying is "if you say > it > >> enough times then people will believe it is true". > >> >> > >> >> If you are just going to stand by and let "trolls" post bad things > about > >> Tapestry unchallenged then they have won the argument - regardless of > how > >> bad their argument may be and how incorrect their views may be. > >> >> > >> >> After all, someone pitching up and wanting a framework will read what > >> they've written and believe it. Who is to say these anti-Tapestry people > are > >> wrong? Not you - because you won't counter their arguments! :-) > >> >> > >> >> Sure - don't feed the trolls. But all that is necessary is to say > >> something positive; not engage them in an argument. > >> >> > >> >> Merry Xmas everyone. > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] > >> >> Sent: 22 December 2009 15:26 > >> >> To: Tapestry users > >> >> Subject: Re: Discussion > >> >> > >> >> Em Tue, 22 Dec 2009 12:45:20 -0200, Banchi Liko <banchi...@gmail.com > > > >> >> escreveu: > >> >> > >> >>> Hi guys, > >> >> > >> >> Hi! > >> >> > >> >>> There is a discussion going on here > >> >>> http://www.theserverside.com/news/thread.tss?thread_id=58858 and > seems > >> >>> like Tapestry ihas already been ruled out as a viable and serious > web > >> >>> framework. > >> >> > >> >> TheServerSide comments has too many trolls to have a good, reasonable > >> >> discussion there. > >> >> > >> >>> Wicket seems to be the favorite. > >> >> > >> >> Some people who bother to post there like Wicket. Most people who > like > >> >> Tapestry, maybe all of them, don't bother to post there. > >> >> > >> >>> I'm sad Tapestry has lost the battle and afraid it might die soon. > >> >> > >> >> Please source or explain your statements or you'll be treated like a > >> troll > >> >> here. > >> >> > >> >>> Please go and contribute and let your voice be > >> >>> heard before Tapestry dies a horrible death. > >> >> > >> >> No, thank you. Posting there will not change Tapestry's fate. Using > it, > >> >> exchanging ideas in the mailing lists and contributing code will (and > >> >> already is). > >> >> > >> >> -- > >> >> Thiago H. de Paula Figueiredo > >> >> Independent Java, Apache Tapestry 5 and Hibernate consultant, > developer, > >> >> and instructor > >> >> Owner, software architect and developer, Ars Machina Tecnologia da > >> >> Informação Ltda. > >> >> http://www.arsmachina.com.br > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > Howard M. Lewis Ship > >> > > >> > Creator of Apache Tapestry > >> > > >> > The source for Tapestry training, mentoring and support. Contact me to > >> > learn how I can get you up and productive in Tapestry fast! > >> > > >> > (971) 678-5210 > >> > http://howardlewisship.com > >> > > >> > >> > >> > >> -- > >> Howard M. Lewis Ship > >> > >> Creator of Apache Tapestry > >> > >> The source for Tapestry training, mentoring and support. Contact me to > >> learn how I can get you up and productive in Tapestry fast! > >> > >> (971) 678-5210 > >> http://howardlewisship.com > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> > >> > > > > > > -- > Howard M. Lewis Ship > > Creator of Apache Tapestry > > The source for Tapestry training, mentoring and support. Contact me to > learn how I can get you up and productive in Tapestry fast! > > (971) 678-5210 > http://howardlewisship.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
