Ok, here is an example.. hope it's legible. :) The meat of the code is
the ContextFilterRequest below. If you create a normal J2EE filter that
determines what part of the path to rip out, then if can do:
doFilter(...) {
String path = getCleanPath( request ); // helper method
boolean hasVirtualHost = //does path start with virtual host//;
if ( hasVirtualHost ) {
String virtualHostPathPart = //virtual host path from path//;
request.setAttribute( "SITEINFO", virtualHostPathPart );
// most stuff to setup siteinfo //
request = new ContextFilterRequest( virtualHostPathPart, request );
}
chain( request, response );
}
//does path start with virtual host//
here you would search your expected virtual host to path listing
( /site1, /site2 )
//virtual host path from path//
here you capture the part of the path you want to gobble up..
and it will be removed from path, and move to contextPath
/site1
// most stuff to setup siteinfo //
a simple way to tell the rest of the program what site is currently
using, is to set a Request.attribute. But you could come up with
other mechanisms ( thread scoped services, etc, etc ), or other
work you need to do to setup the site info ( load more config from
else where, etc ).
public static String getCleanPath( HttpServletRequest request ) {
String fullpath = request.getRequestURI();
String contextPath = request.getContextPath();
String path = fullpath.substring( contextPath.length() );
return path;
}
public static class ContextFilterRequest extends HttpServletRequestWrapper {
protected static Logger logger = Logger.getLogger(
ContextFilterRequest.class );
private String contextPart;
private String context;
private String servletPath;
public ContextFilterRequest( String context, HttpServletRequest request
) {
super( request );
this.contextPart = context;
this.context = super.getContextPath() + "/" + contextPart;
this.servletPath = super.getServletPath().substring(
contextPart.length() + 1 );
}
@Override
public String getContextPath() {
return context;
}
@Override
public String getServletPath() {
return servletPath;
}
@Override
public String getRealPath( String path ) {
if ( path.startsWith( "/" ) ) {
path = "/" + contextPart + path;
}
return super.getRealPath( path );
}
@Override
public RequestDispatcher getRequestDispatcher( String path ) {
if ( path.startsWith( "/" ) ) {
path = "/" + contextPart + path;
}
return super.getRequestDispatcher( path );
}
}
xfile80303 wrote:
Thanks Fernando.
I'm interested in option 2 below. If you have code to share, please do. :)
What I'm trying to solve for is not really virtual hosting. I want to have
the ability to have multiple "sites," sure, but these sites all use the same
pages and page structure and only differ by configuration information which
is keyed off the site name. The sub-directory approach is certainly what I
want, but Tapestry's way of handling this would require me to duplicate
every page into a peer package structure, which is not maintainable, not
dynamic, and not an option.
Cheers,
Levi
Fernando Padilla 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
