ICompStrings doesn't change with Locale

["Howard M. Lewis Ship" <hl...@attbi.com>]

Sorry this is a bit hard to follow.

There's a structural issue inside Tapestry.  Here's an outline of the
constraints.

The engine locale may change at any time.
A page is loaded at most once per request cycle.
A page is loaded matching the engine locale at that time.
A page's locale may not change.

#4 is a bitter pill to swallow, but you have to understand the history.  In
the beginning (Feb 2000) when I started noodling on how localization would
work, I realized I could leverage the split between the page specification,
the HTML template and the Java class.  I could have a one-to-many
relationship between a page spec and HTML template.

This is still allowed and occasionally useful!  Remember that a page is
constructed from components and each component may have a template and each
template may be localized.  In 2.4, through the use of implicit components
(and even in 2.3, if you are willing to ignore some runtime warnings),
different localizations of the same template can have different components!

That means there is no simple way to convert the locale of a page.  The
effort involved is nearly equivalent to constructing a new instance of the
page hierachy (that is, all the page objects, component objects, templates,
bindings and other structure).

So that's the technical reason for why a page's locale is fixed.  You can
see why I'm struggling with with this.

My current solution involves some fakery (having the component strings
change immediately, or at least, on first access) and loading a new page
instance to render the result ... but I then have to solve the issues of
transient page state being lost..



----- Original Message -----
From: "SourceForge.net" <no...@sourceforge.net>
To: <no...@sourceforge.net>
Sent: Tuesday, January 28, 2003 7:41 PM
Subject: [Tapestry-developer] [ tapestry-Bugs-614322 ] ICompStrings doesn't
change with Locale


> Bugs item #614322, was opened at 2002-09-25 10:49
> You can respond by visiting:
>
https://sourceforge.net/tracker/?func=detail&atid=104754&aid=614322&group_id
=4754
>
> Category: Tapestry
> Group: bug
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Tzvetelin (tzvetelin)
> Assigned to: Howard Lewis Ship (hship)
> Summary: ICompStrings doesn't change with Locale
>
> Initial Comment:
> IComponentStrings doesn't change when the locale
> changes in IEngine.
> I think this is necessary, because if an application
> receives a user request to change its locale, a
> component will use the old localized strings, since it
> caches them.
> One possible implementation is to cache the
> IComponentStrings in IComponentStringSource instead
> of the component itself, make the implementation a
> locale listener of IEngine, and have it flush its cache
> when the Locale changes.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Christian Sell (csell)
> Date: 2003-01-29 00:41
>
> Message:
> Logged In: YES
> user_id=105319
>
> I cant say that I fully understand the code sample given
> below, nor the underlying architectural problem, but to me
> this does not look much nicer than the PageRedirectException
> suggested elsewhere.
>
> Is there no way to just register some listener, and reload
> the strings, as tzvetelin wrote?
>
> ----------------------------------------------------------------------
>
> Comment By: Howard Lewis Ship (hship)
> Date: 2003-01-28 22:56
>
> Message:
> Logged In: YES
> user_id=26816
>
> I may have to kludge component strings in some way; the
> problem is, once you are inside a listener method of a loaded
> page, the locale for the page is fixed, as is the strings.  It
> may take a two pass to get the right localized messages, i.e.
>
> public class ThisPage ...
> {
> public void listener(IRequestCycle cycle)
> {
>   getEngine().setLocale(foo);
>
>   ThisPage thisPage = (ThisPage)cycle.getPage("ThisPage");
>
>   thisPage.continueListener(cycle);
> }
>
> public void continueListener(IRequestCycle cycle)
> {
>    setMessage(getString(...)));
> }
>
>
> ----------------------------------------------------------------------
>
> Comment By: Christian Sell (csell)
> Date: 2003-01-15 18:43
>
> Message:
> Logged In: YES
> user_id=105319
>
> for reference, heres my usage scenario
>
> On one of my pages, I am using an Insert component with a
> string-binding parameter. On the same page, I have a form
> with a Select component which allows setting the Locale.
> After setting the locale, the same page is redisplayed.
>
> Now it turns out that when the locale is set, the Insert
> element does not change its appearance according to the new
> locale. Only after visiting another page and returning to
> the previous one, the new localized string is shown.
>
> ----------------------------------------------------------------------
>
> Comment By: Christian Sell (csell)
> Date: 2003-01-15 18:39
>
> Message:
> Logged In: YES
> user_id=105319
>
> the problem is two-fold:
>
> 1. as the request describes, localized strings are cached in
> the component after creation and do not change even if the
> engine locale is changed. That means that if the same
> component is rendered after changing the locale, it displays
> the wrong strings. The only workaround is to force a
> redirect, which causes the component to be recreated.
>
> 2. the class StringBinding implements the isInvariant()
> method by returning true. That means that the binding is
> only evaluated once after the component is created, so that
> even if the strings were updated (see 1.), they would not be
> accessed.
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
>
https://sourceforge.net/tracker/?func=detail&atid=104754&aid=614322&group_id
=4754
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Tapestry-developer mailing list
> Tapestry-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tapestry-developer
>

Re: ICompStrings doesn't change with Locale

[Christian Sell <ch...@netcologne.de>]

yes, after thinking some more I came to the conclusion myself that your 
problem was this case where a whole component template could be replaced 
depending on the locale.

I think it would be acceptable if the strings changed immediately, but 
page-reinstantiation remained under the current (documented) 
restrictions, i.e. "if you use localized templates, keep in mind that 
the page locale changes are not reflected until the next request cycle"

Forcing the whole re-instantiation machinery on components that only do 
string localization seems like an undesirable resource overhead, too.

Maybe it would even be possible to detect the case where 
re-instantiation would be required in the same request cycle, and throw 
an exception?


Howard M. Lewis Ship wrote:
> Sorry this is a bit hard to follow.
> 
> There's a structural issue inside Tapestry.  Here's an outline of the
> constraints.
> 
> The engine locale may change at any time.
> A page is loaded at most once per request cycle.
> A page is loaded matching the engine locale at that time.
> A page's locale may not change.
> 
> #4 is a bitter pill to swallow, but you have to understand the history.  In
> the beginning (Feb 2000) when I started noodling on how localization would
> work, I realized I could leverage the split between the page specification,
> the HTML template and the Java class.  I could have a one-to-many
> relationship between a page spec and HTML template.
> 
> This is still allowed and occasionally useful!  Remember that a page is
> constructed from components and each component may have a template and each
> template may be localized.  In 2.4, through the use of implicit components
> (and even in 2.3, if you are willing to ignore some runtime warnings),
> different localizations of the same template can have different components!
> 
> That means there is no simple way to convert the locale of a page.  The
> effort involved is nearly equivalent to constructing a new instance of the
> page hierachy (that is, all the page objects, component objects, templates,
> bindings and other structure).
> 
> So that's the technical reason for why a page's locale is fixed.  You can
> see why I'm struggling with with this.
> 
> My current solution involves some fakery (having the component strings
> change immediately, or at least, on first access) and loading a new page
> instance to render the result ... but I then have to solve the issues of
> transient page state being lost..
> 
> 
> 
> ----- Original Message -----
> From: "SourceForge.net" <no...@sourceforge.net>
> To: <no...@sourceforge.net>
> Sent: Tuesday, January 28, 2003 7:41 PM
> Subject: [Tapestry-developer] [ tapestry-Bugs-614322 ] ICompStrings doesn't
> change with Locale
> 
> 
> 
>>Bugs item #614322, was opened at 2002-09-25 10:49
>>You can respond by visiting:
>>
> 
> https://sourceforge.net/tracker/?func=detail&atid=104754&aid=614322&group_id
> =4754
> 
>>Category: Tapestry
>>Group: bug
>>Status: Open
>>Resolution: None
>>Priority: 5
>>Submitted By: Tzvetelin (tzvetelin)
>>Assigned to: Howard Lewis Ship (hship)
>>Summary: ICompStrings doesn't change with Locale
>>
>>Initial Comment:
>>IComponentStrings doesn't change when the locale
>>changes in IEngine.
>>I think this is necessary, because if an application
>>receives a user request to change its locale, a
>>component will use the old localized strings, since it
>>caches them.
>>One possible implementation is to cache the
>>IComponentStrings in IComponentStringSource instead
>>of the component itself, make the implementation a
>>locale listener of IEngine, and have it flush its cache
>>when the Locale changes.
>>
>>
>>----------------------------------------------------------------------
>>
>>Comment By: Christian Sell (csell)
>>Date: 2003-01-29 00:41
>>
>>Message:
>>Logged In: YES
>>user_id=105319
>>
>>I cant say that I fully understand the code sample given
>>below, nor the underlying architectural problem, but to me
>>this does not look much nicer than the PageRedirectException
>>suggested elsewhere.
>>
>>Is there no way to just register some listener, and reload
>>the strings, as tzvetelin wrote?
>>
>>----------------------------------------------------------------------
>>
>>Comment By: Howard Lewis Ship (hship)
>>Date: 2003-01-28 22:56
>>
>>Message:
>>Logged In: YES
>>user_id=26816
>>
>>I may have to kludge component strings in some way; the
>>problem is, once you are inside a listener method of a loaded
>>page, the locale for the page is fixed, as is the strings.  It
>>may take a two pass to get the right localized messages, i.e.
>>
>>public class ThisPage ...
>>{
>>public void listener(IRequestCycle cycle)
>>{
>>  getEngine().setLocale(foo);
>>
>>  ThisPage thisPage = (ThisPage)cycle.getPage("ThisPage");
>>
>>  thisPage.continueListener(cycle);
>>}
>>
>>public void continueListener(IRequestCycle cycle)
>>{
>>   setMessage(getString(...)));
>>}
>>
>>
>>----------------------------------------------------------------------
>>
>>Comment By: Christian Sell (csell)
>>Date: 2003-01-15 18:43
>>
>>Message:
>>Logged In: YES
>>user_id=105319
>>
>>for reference, heres my usage scenario
>>
>>On one of my pages, I am using an Insert component with a
>>string-binding parameter. On the same page, I have a form
>>with a Select component which allows setting the Locale.
>>After setting the locale, the same page is redisplayed.
>>
>>Now it turns out that when the locale is set, the Insert
>>element does not change its appearance according to the new
>>locale. Only after visiting another page and returning to
>>the previous one, the new localized string is shown.
>>
>>----------------------------------------------------------------------
>>
>>Comment By: Christian Sell (csell)
>>Date: 2003-01-15 18:39
>>
>>Message:
>>Logged In: YES
>>user_id=105319
>>
>>the problem is two-fold:
>>
>>1. as the request describes, localized strings are cached in
>>the component after creation and do not change even if the
>>engine locale is changed. That means that if the same
>>component is rendered after changing the locale, it displays
>>the wrong strings. The only workaround is to force a
>>redirect, which causes the component to be recreated.
>>
>>2. the class StringBinding implements the isInvariant()
>>method by returning true. That means that the binding is
>>only evaluated once after the component is created, so that
>>even if the strings were updated (see 1.), they would not be
>>accessed.
>>
>>----------------------------------------------------------------------
>>
>>You can respond by visiting:
>>
> 
> https://sourceforge.net/tracker/?func=detail&atid=104754&aid=614322&group_id
> =4754
> 
>>
>>-------------------------------------------------------
>>This SF.NET email is sponsored by:
>>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>>http://www.vasoftware.com
>>_______________________________________________
>>Tapestry-developer mailing list
>>Tapestry-developer@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/tapestry-developer
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
>