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
