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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- 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
