Thanks Peter, You're suggestion is /almost/ a solution for what I'm trying to do.
Perhaps I'm missing something in your description, but the issue I'm trying to solve is not to have a different package structure (or different pages) for each site. They will all use the same pages and page flow, but will key off of the site name (as supplied in the URL). Inserting a RequestFilter to get the page name out of the request is, as you point out, easy, but making Tapestry work with this extra bit of information in the URL without actually having a page located at the URL specified "package" is proving to be quite a challenge. For instance, if I have the URL structure as you mention: http://host/context/site/page/params Tapestry will look for a page in the "site" package, but since this is a dynamic value and does not actually exist it doesn't work. I have been trying to find a way to get Tapestry to allow this extra data in the URL and persist it from call to call, but, as I said, I'm struggling. Thanks, Levi Peter Stavrinides wrote: > > Hi, > > It just so happens I had a similar use case, and it is actually blindingly > easy to emulate a virtual site (a portlet style site if you prefer). To > begin avoid using context parameters, that could get very messy as already > mentioned, rather prefer a Restful style URL to map your path. Of course > this means its better that your package structure matches, otherwise you > will have to do a lot of URL rewriting: > > - Create a simple enumeration like this one: > public enum Site { > > SITEA("Site A","/sitea/"), > SITEB("Site B","/siteb/"), > SITEA1("Site A1","/sitea/one/"), > SITEA2("Site A2","/sitea/two/"), > ... > > private final String title_; > private final String path_; > > private Site(String title,String path) { > title_ = title; > path_ = path; > } > > - Use a RequestFilter to filter page requests (use request.getPath()), and > do a simple check on the path using indexOf, i.e.: > path.indexOf(Site.SITEA.getPath()) > - Create an ASO for site permissions, which you should populate when a > user logs in > - Wire the filter to your ApplicationStateManager, to get at the ASO use: > applicationStateManager.get(permissionsASO.class); > - When you Filter on the request (extracting the site from your path), > check permissions at the same time, so when the user navigates to a > subsection you can react before the page is even served. > > The URL will look very clean, like this: > http://host/context/site/page/params > > Remember to use the same page and component package structure: > pages.site.subsection > > I also found its a good idea to use a convention for a home page for each > virtual site. (i.e.: /home) That way in your request filter you can > redirect without having to think about building links or doing page > lookups, just build up a URL: /site/home. > > Cheers, > Peter > > > > ----- Original Message ----- > From: "Howard Lewis Ship" <hls...@gmail.com> > To: "Tapestry users" <users@tapestry.apache.org> > Sent: Sunday, 15 February, 2009 21:20:46 GMT +02:00 Athens, Beirut, > Bucharest, Istanbul > Subject: Re: [T5] Struggling With Concepts > > Why would you use other filters or servlets when you have Tapestry? :-) > > On Sun, Feb 15, 2009 at 11:13 AM, Fernando Padilla <f...@alum.mit.edu> > wrote: >> Fair, but then the knowledge of "virtual host" would only be within >> tapestry, and not be usable for any other filters, servlets, etc etc.. >> just >> get to pick your poison :) >> >> >> Howard Lewis Ship wrote: >>> >>> Acutally, there's no real reason Tapestry 5.1 can't support this >>> scheme, once we make a few more of the Link-generating and >>> Request-path-parsing services public and overridable. >>> >>> On Sat, Feb 14, 2009 at 6:48 PM, Fernando Padilla <f...@alum.mit.edu> >>> wrote: >>>> >>>> I'm sorry, but this is not quite what Tapestry is meant to solve for.. >>>> It >>>> solves nicely for state within a page.. or within a user's session, etc >>>> etc. >>>> >>>> Since what you're trying to do is have your code support a form of >>>> "virtual >>>> hosting", it might be easier if you deal with it using normal J2EE >>>> mechanisms. >>>> >>>> 1) As Onno suggested, if your virtual hosts can be mapped to different >>>> sub-domains, your code could simply look at the sub-domain to determine >>>> how >>>> to behave: HttpServletRequest.getHost() >>>> >>>> 2) If you want a subdirectory method: >>>> http://host/context/typeA/.... >>>> http://host/context/typeB/.... >>>> >>>> We do this easily by adding a normal J2EE Filter that detects the >>>> "typeA" >>>> part and strips it out (adding it to the contextPath, and some request >>>> attribute for later logic). After it's been added to the contextPath, >>>> then >>>> tapestry (or any filter/servlet after this filter) would never have to >>>> deal >>>> with the "typeA" part of the path, only if they wanted to know which >>>> "type" >>>> it was currently running under, it would look it up under a request >>>> attribute or some such ( or look it up through the contextPath ). If >>>> this >>>> could serve your purposes, I could share some code ( really small ).. >>>> >>>> >>>> >>>> On 2/13/09 6:16 PM, xfile80303 wrote: >>>>> >>>>> Hello all, >>>>> >>>>> I've been struggling to understand the concepts surrounding T5 and >>>>> have >>>>> reached a pinnacle of frustration while trying to implement a >>>>> (supposedly) >>>>> simple piece of functionality. I could very much use some guidance. >>>>> >>>>> What I'm trying to do is have a piece of information specifiable on >>>>> the >>>>> URL >>>>> which will persist throughout the experience of the user. >>>>> >>>>> Specifically, I am trying to create an application which will be "site >>>>> aware" (where "site" is a made-up term which implies different >>>>> configurations/access/etc.). The "site" will need to be present in >>>>> the >>>>> URL >>>>> in some form. With URL re-writing I suppose it is possible to have >>>>> this >>>>> as >>>>> a parameter on the URL, or some other way which can be re-written into >>>>> a >>>>> Tapestry compatible form, but even so, I'm not sure what approach that >>>>> form >>>>> should take. >>>>> >>>>> If it is a parameter on the URL, how will that parameter persist while >>>>> the >>>>> user is browsing through the app, submitting forms, clicking links, >>>>> etc? >>>>> >>>>> If it is an activation context, how would /that/ persist? >>>>> >>>>> Ultimately the ideal solution would be to have this "site" specified >>>>> early >>>>> in the URL and have Tapestry keep it there (and allow me to access its >>>>> value) throughout the use of the app by a client. >>>>> >>>>> Something like: >>>>> >>>>> http://mysite.com/foosite/blah/blah/blah >>>>> >>>>> where "foosite" would be any string. >>>>> >>>>> As mentioned above, I suppose this could be: >>>>> >>>>> http://mysite.com/blah/blah/blah?site=foosite >>>>> >>>>> or >>>>> >>>>> http://mysite.com/blah/blah/blah/foosite >>>>> >>>>> if that makes achieving this with Tapestry any easier. >>>>> >>>>> I feel that Tapestry has the potential to be very useful and a great >>>>> platform to develop on, but I'm really struggling to understand how to >>>>> do >>>>> this. >>>>> >>>>> Many Thanks, >>>>> >>>>> Levi >>>>> --- >>>>> For reference, here is a my previous thread: >>>>> http://n2.nabble.com/-T5--URL-Manipulation-tt2276010.html >>>> >>>> --------------------------------------------------------------------- >>>> 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 Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > 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 > > > -- View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2341859.html Sent from the Tapestry Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
