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
