You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Kent Tong <ke...@cpttm.org.mo> on 2006/12/22 11:08:40 UTC
T5: how to persist the locale
Hi,
The persistent locale is stored as a cookie in T4. Is this still the desired
behavior? An alternative is to store it into the session:
PROs:
1) The LocalizationFilter can store the thread locale into the session if
it's changed. As it is setting the thread locale from the request, this
is a well-balanced structure. If it is set as a cookie, when the
LocalizationFilter gets the control back, the output has been rendered
and it is too late to set the cookie. It could buffer the output but this
is probably quite costly in performance.
2) Some people may disable cookies for better security. We are sure a session
is available in our Servlet container.
CONs:
1) A cookie may be better in terms of performance when no session is used.
2) In T4 is cookie is stored for a week, not just for the session. Changing
it will cause a change in behavior.
If cookie is still the preferred way, who should set it? I can think of some
options:
A) LocalizationFilter. It is cleaner but it will need to buffer the output.
B) ComponentEventDispatcher.
Any idea?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: how to persist the locale
Posted by RonPiterman <rp...@gmx.net>.
Howard Lewis Ship wrote:
> I think we'll end up duplicating the Tapestry 4 behavior for the most part,
> with a little more ability to customize it.
>
> We do need some kind of LocaleManager service that is responsible for
> storing the locale as a cookie and in the session (if the session already
> exists).
>
> I feel the cookie should outlive the session, so that when people return to
> the site at a later date, they can view the site in the appropriate locale.
> I thnk of it as a kind of "bootstrapping" property.
interresting - just a thought: one could also expose this "bootstraping"
cookie as a service, letting the application developer add other
"bootstrapping" properties which stay persist across sessions.
>
> The alternative would be to build the locale into the URL. The problem
> with
> that is that once I add in support for templates in the context, I'll want
> to be able to support relative paths to assets. If the locale is in the
> path, that will break it (the template will be at /Start.html, but the base
> URL for rendering the page will be something like /en/Start.html, and a
> relative asset, such as src="images/logo.gif" will evaulate to
> "/en/images/logo.gif" and break).
>
> Oops; just remembered, because of passivate/activate, relative URLs will
> already be broken. I.e., a typical path may be
> "/admin/DisplayUser.html/1234".
>
> Which brings up the nasty thought of post-processing the static HTML,
> looking for things like img/@src and "fixing" the URL in some way. Or just
> requiring that URLs in template be absolute (which then requires that the
> developer know the correct context path).
>
> The Shell component in Tapestry 4 addressed this by putting a <base> tag
> into the output HTML, but that caused more problems than it solved.
>
> So anyway, for the meantime, cookie is the way to go for locale.
>
> On 12/22/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>>
>> Hi,
>>
>> The persistent locale is stored as a cookie in T4. Is this still the
>> desired
>> behavior? An alternative is to store it into the session:
>>
>> PROs:
>> 1) The LocalizationFilter can store the thread locale into the session if
>> it's changed. As it is setting the thread locale from the request, this
>> is a well-balanced structure. If it is set as a cookie, when the
>> LocalizationFilter gets the control back, the output has been rendered
>> and it is too late to set the cookie. It could buffer the output but this
>> is probably quite costly in performance.
>>
>> 2) Some people may disable cookies for better security. We are sure a
>> session
>> is available in our Servlet container.
>>
>> CONs:
>> 1) A cookie may be better in terms of performance when no session is
>> used.
>> 2) In T4 is cookie is stored for a week, not just for the session.
>> Changing
>> it will cause a change in behavior.
>>
>> If cookie is still the preferred way, who should set it? I can think of
>> some
>> options:
>> A) LocalizationFilter. It is cleaner but it will need to buffer the
>> output.
>> B) ComponentEventDispatcher.
>>
>> Any idea?
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: how to persist the locale
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah, but you guys should keep in mind that those cookies do come at a
cost..Ie cookies still get sent around on each request...
I wish I had more time to play with it but I've been really curious
what kind of "efficiencies" (however slight) might be had by making
more use of other kinds of client side storage constructs.. Firefox 2
has a built in native type for it now, the other browsers can have the
same thing through varying types of native objects. (usually flash /
activex )
Either way they are all in Dojo and can be accessed through one single
interface that allows you to not care what is happening and all should
be very fast going from server->client && client->server.
Now that I've got FireBug installed it's always worrisome when I see
larger than normal cookie strings getting passed around. :) (maybe
more worrisome in an ocd way than normal? ...)
On 12/22/06, Kent Tong <ke...@cpttm.org.mo> wrote:
<snipped>
> > The alternative would be to build the locale into the URL. The problem with
> > that is that once I add in support for templates in the context, I'll want
> > to be able to support relative paths to assets. If the locale is in the
> > path, that will break it (the template will be at /Start.html, but the base
> > URL for rendering the page will be something like /en/Start.html, and a
> > relative asset, such as src="images/logo.gif" will evaulate to
> > "/en/images/logo.gif" and break).
>
> I think this will also go against the principle of that a URL should
> represent a resource, not a particular presentation of a resource.
>
<snipped>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: how to persist the locale
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
> I feel the cookie should outlive the session, so that when people return to
> the site at a later date, they can view the site in the appropriate locale.
> I thnk of it as a kind of "bootstrapping" property.
I see.
> The alternative would be to build the locale into the URL. The problem with
> that is that once I add in support for templates in the context, I'll want
> to be able to support relative paths to assets. If the locale is in the
> path, that will break it (the template will be at /Start.html, but the base
> URL for rendering the page will be something like /en/Start.html, and a
> relative asset, such as src="images/logo.gif" will evaulate to
> "/en/images/logo.gif" and break).
I think this will also go against the principle of that a URL should
represent a resource, not a particular presentation of a resource.
> Oops; just remembered, because of passivate/activate, relative URLs will
> already be broken. I.e., a typical path may be
> "/admin/DisplayUser.html/1234".
Possible to let the PageRenderDispatcher sets the Content-Location HTTP
header to /admin/DisplayUser.html?
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: how to persist the locale
Posted by Howard Lewis Ship <hl...@gmail.com>.
I think we'll end up duplicating the Tapestry 4 behavior for the most part,
with a little more ability to customize it.
We do need some kind of LocaleManager service that is responsible for
storing the locale as a cookie and in the session (if the session already
exists).
I feel the cookie should outlive the session, so that when people return to
the site at a later date, they can view the site in the appropriate locale.
I thnk of it as a kind of "bootstrapping" property.
The alternative would be to build the locale into the URL. The problem with
that is that once I add in support for templates in the context, I'll want
to be able to support relative paths to assets. If the locale is in the
path, that will break it (the template will be at /Start.html, but the base
URL for rendering the page will be something like /en/Start.html, and a
relative asset, such as src="images/logo.gif" will evaulate to
"/en/images/logo.gif" and break).
Oops; just remembered, because of passivate/activate, relative URLs will
already be broken. I.e., a typical path may be
"/admin/DisplayUser.html/1234".
Which brings up the nasty thought of post-processing the static HTML,
looking for things like img/@src and "fixing" the URL in some way. Or just
requiring that URLs in template be absolute (which then requires that the
developer know the correct context path).
The Shell component in Tapestry 4 addressed this by putting a <base> tag
into the output HTML, but that caused more problems than it solved.
So anyway, for the meantime, cookie is the way to go for locale.
On 12/22/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>
> Hi,
>
> The persistent locale is stored as a cookie in T4. Is this still the
> desired
> behavior? An alternative is to store it into the session:
>
> PROs:
> 1) The LocalizationFilter can store the thread locale into the session if
> it's changed. As it is setting the thread locale from the request, this
> is a well-balanced structure. If it is set as a cookie, when the
> LocalizationFilter gets the control back, the output has been rendered
> and it is too late to set the cookie. It could buffer the output but this
> is probably quite costly in performance.
>
> 2) Some people may disable cookies for better security. We are sure a
> session
> is available in our Servlet container.
>
> CONs:
> 1) A cookie may be better in terms of performance when no session is used.
> 2) In T4 is cookie is stored for a week, not just for the session.
> Changing
> it will cause a change in behavior.
>
> If cookie is still the preferred way, who should set it? I can think of
> some
> options:
> A) LocalizationFilter. It is cleaner but it will need to buffer the
> output.
> B) ComponentEventDispatcher.
>
> Any idea?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com