You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by xfile80303 <le...@grokers.net> on 2009/02/14 03:16:08 UTC
[T5] Struggling With Concepts
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
--
View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2324920.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Onno Scheffers <on...@piraya.nl>.
> 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.
I don't know how many sites you are offering, but have you thought about
using different domains or subdomains? Then http://site1.mysite.com and
http://site2.mysite.com would get you into the different sites for example.
By injecting the Request into your pages and components you can determine
what to do and there is no need for url-rewriting.
We are using a single application to serve a full version of our product and
a light-version, which both have their own url. Based on the url you used
for accessing the application the correct welcome page/site style is shown
and after the user logged in we know which plan (s)he has purchased and can
forward the user to correct url. In the light version there are less pages
available (the pages of the full version return a 404 if you don't have a
subscription to the premium service). Also components can render paths to
different pages based on the active version for the user.
We are using subdomains to indicate acceptance and test-environment and
while developing we support an url-parameter on the home-page to switch
site-mode to ease local testing.
regards,
Onno
Re: [T5] Struggling With Concepts
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Tue, 17 Feb 2009 13:47:16 -0300, xfile80303 <le...@grokers.net> escreveu:
> I know this was sort of a "tongue-in-cheek" comment, but how can I use
> Tapestry to solve this dilemma?
Not very much tongue-in-cheek, I guess. A Tapestry Dispatcher is the
analogous to a servlet, and a Tapestry RequestFilter is analogous to a
servlet filter. But Dispatcher and RequestFilter have one big advantage:
they have access to all the features provided by Tapestry and
Tapestry-IoC, including dependency injection.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by xfile80303 <le...@grokers.net>.
I know this was sort of a "tongue-in-cheek" comment, but how can I use
Tapestry to solve this dilemma?
Howard Lewis Ship wrote:
>
> Why would you use other filters or servlets when you have Tapestry? :-)
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
--
View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2341876.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Howard Lewis Ship <hl...@gmail.com>.
Why would you use other filters or servlets when you have Tapestry? :-)
On Sun, Feb 15, 2009 at 11:13 AM, Fernando Padilla <fe...@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 <fe...@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-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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 <fe...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <fe...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by xfile80303 <le...@grokers.net>.
Fernando Padilla wrote:
>
> 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:
>
Thanks Fernando, I appreciate you taking the time.
--
View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2344202.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by xfile80303 <le...@grokers.net>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2341790.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Fernando Padilla <fe...@alum.mit.edu>.
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by xfile80303 <le...@grokers.net>.
Luther Baker wrote:
>
> From your perspective, how does 'site' differ from the application
> context?
>
> -Luther
>
Well, that's a great question, and may hilight my conceptual difficulties.
It is my understanding that the application context is really more of a page
context and does not persist from page to page as links are clicked and
forms posted, so that context would be lost for the application as a whole,
without some contortionist mechanism to insert the context into every
generated link, etc.
Please tell me I'm missing something.
Levi
--
View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2341894.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Luther Baker <lu...@gmail.com>.
>From your perspective, how does 'site' differ from the application context?
-Luther
On Fri, Feb 13, 2009 at 8:16 PM, xfile80303 <le...@grokers.net> 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
> --
> View this message in context:
> http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2324920.html
> Sent from the Tapestry Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [T5] Struggling With Concepts
Posted by xfile80303 <le...@grokers.net>.
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" <hl...@gmail.com>
> To: "Tapestry users" <us...@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 <fe...@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 <fe...@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-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Fernando Padilla <fe...@alum.mit.edu>.
This is basically the same technique I was outlining.. just implemented
using a Tapestry RequestFilter, instead of a normal J2EE Filter. If
done properly, there should be no more modifications required within
tapestry.
Robert Zeigler wrote:
> Not necessarily.
> If you intercept the request via a RequestFilter, ordered early, then
> you can pull the site information out that you want, right (and store it
> someplace useful that you'll use later on when rendering; like in an ASO).
> And then you can wrap the original request with a custom implementation
> that returns the site-less path that tapestry will use to determine
> which page/component to render. The page to render isn't determined
> until control flows to the MasterDispatcher, from RequestFilter, so
> intercepting via RequestFilter should let you do this.
>
> From your other posts, it looks like you've already got the link
> implementation in place to add the site /back/ into any links generated
> for the next request. Between the request filter and the link
> implementation, you should be set...? (Apologies, I haven't been
> following this conversation very closely, so, if I'm missing something,
> fill me in).
>
> Robert
>
> On Feb 18, 2009, at 2/1811:02 AM , xfile80303 wrote:
>
>>
>> Hi Peter,
>>
>> But, if I follow you correctly, there will still need to be a class,
>> even if
>> empty, with the desired path as its package for every "site." I'm
>> trying to
>> make the site a dynamic configuration which does not need the addition of
>> more pages.
>>
>> Cheers,
>>
>> Levi
>>
>>
>> Peter Stavrinides wrote:
>>>
>>>> They will all use the same pages and page flow, but will key
>>>> off of the site name
>>> Sorry but I don't get this comment? I mean what exactly are you
>>> trying to
>>> do?... Tapestry uses composition, so construct components instead of
>>> pages,, embed those components in your pages (just empty containers
>>> really, with different settings, "parameters", you duplicate nothing
>>> this
>>> way), set a site parameter in your component according, whose value
>>> corresponds with the containing page (your site /sub-section), and thats
>>> it.
>>>
>>> component A (shared)
>>> / \
>>> page 1 (@parameter site = A) page 2 (@parameter site=B)
>>>
>>> cheers,
>>> Peter
>>>
>>
>> --
>> View this message in context:
>> http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2348095.html
>> Sent from the Tapestry Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by xfile80303 <le...@grokers.net>.
Thanks Robert,
Yeah, that's been a common thread, and I think I have it (not the specific
implementation you mention, but close) figured out:
http://n2.nabble.com/-T5--URL-Manipulation-tp2276010p2344257.html
Cheers!
Levi
Robert Zeigler wrote:
>
> Not necessarily.
> If you intercept the request via a RequestFilter, ordered early, then
> you can pull the site information out that you want, right (and store
> it someplace useful that you'll use later on when rendering; like in
> an ASO).
> And then you can wrap the original request with a custom
> implementation that returns the site-less path that tapestry will use
> to determine which page/component to render. The page to render
> isn't determined until control flows to the MasterDispatcher, from
> RequestFilter, so intercepting via RequestFilter should let you do this.
>
> From your other posts, it looks like you've already got the link
> implementation in place to add the site /back/ into any links
> generated for the next request. Between the request filter and the
> link implementation, you should be set...? (Apologies, I haven't been
> following this conversation very closely, so, if I'm missing
> something, fill me in).
>
> Robert
>
--
View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2348257.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by Robert Zeigler <ro...@scazdl.org>.
Not necessarily.
If you intercept the request via a RequestFilter, ordered early, then
you can pull the site information out that you want, right (and store
it someplace useful that you'll use later on when rendering; like in
an ASO).
And then you can wrap the original request with a custom
implementation that returns the site-less path that tapestry will use
to determine which page/component to render. The page to render
isn't determined until control flows to the MasterDispatcher, from
RequestFilter, so intercepting via RequestFilter should let you do this.
From your other posts, it looks like you've already got the link
implementation in place to add the site /back/ into any links
generated for the next request. Between the request filter and the
link implementation, you should be set...? (Apologies, I haven't been
following this conversation very closely, so, if I'm missing
something, fill me in).
Robert
On Feb 18, 2009, at 2/1811:02 AM , xfile80303 wrote:
>
> Hi Peter,
>
> But, if I follow you correctly, there will still need to be a class,
> even if
> empty, with the desired path as its package for every "site." I'm
> trying to
> make the site a dynamic configuration which does not need the
> addition of
> more pages.
>
> Cheers,
>
> Levi
>
>
> Peter Stavrinides wrote:
>>
>>> They will all use the same pages and page flow, but will key
>>> off of the site name
>> Sorry but I don't get this comment? I mean what exactly are you
>> trying to
>> do?... Tapestry uses composition, so construct components instead of
>> pages,, embed those components in your pages (just empty containers
>> really, with different settings, "parameters", you duplicate
>> nothing this
>> way), set a site parameter in your component according, whose value
>> corresponds with the containing page (your site /sub-section), and
>> thats
>> it.
>>
>> component A (shared)
>> / \
>> page 1 (@parameter site = A) page 2 (@parameter site=B)
>>
>> cheers,
>> Peter
>>
>
> --
> View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2348095.html
> Sent from the Tapestry Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5] Struggling With Concepts
Posted by xfile80303 <le...@grokers.net>.
Hi Peter,
But, if I follow you correctly, there will still need to be a class, even if
empty, with the desired path as its package for every "site." I'm trying to
make the site a dynamic configuration which does not need the addition of
more pages.
Cheers,
Levi
Peter Stavrinides wrote:
>
>> They will all use the same pages and page flow, but will key
>> off of the site name
> Sorry but I don't get this comment? I mean what exactly are you trying to
> do?... Tapestry uses composition, so construct components instead of
> pages,, embed those components in your pages (just empty containers
> really, with different settings, "parameters", you duplicate nothing this
> way), set a site parameter in your component according, whose value
> corresponds with the containing page (your site /sub-section), and thats
> it.
>
> component A (shared)
> / \
> page 1 (@parameter site = A) page 2 (@parameter site=B)
>
> cheers,
> Peter
>
--
View this message in context: http://n2.nabble.com/-T5--Struggling-With-Concepts-tp2324920p2348095.html
Sent from the Tapestry Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org