[
https://issues.apache.org/jira/browse/TAP5-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703567#action_12703567
]
Andy Blower commented on TAP5-577:
----------------------------------
"The process outlined by Andy doesn't really work because the
ComponentEventLinkEncoder always calls the LocalizationSetter which in turn
always sets the ThreadLocale; thus overriding the set made by the filter. To
make it work I had to override the LocalizationSetter service to always return
false, and change the filter to set the ThreadLocale directly. "
Nice to hear I'm not the only one bothered by this Ferdy, and you're quite
correct on this - I just traced though to double check! The weird thing is what
I've done at least half works... when the filter sets the locale, the messages
displayed on my page are correctly localised even though the thread locale is
subsequently set back to the browser default rather than our persistent locale.
I have no idea why this is and I honestly haven't the time or inclination any
more to look into this problem more so I'm not going to be finding out. I must
have spent 20+ hours on this one issue, looking at code & writing
emails/issues, with absolutely no result. So I have better things to do with
my time, but I definitely think that localisation has become a mess in T5.1
which is a shame since it was so nice to simply contribute a service
implementation of a public interface in 5.0 and the job was done.
I will be following the method you outlined, which will also mean I'll be
following Howards advice from TAP5-658. (you might find that issue interesting
to read also) My filter will also need the fall back to browser request locale
copied from the setter, but that's no biggie. Thanks for the catch as this
probably would have bitten me in the ass in a few months.
> TAP5-422 changes break persistent locale backwards compatibility.
> -----------------------------------------------------------------
>
> Key: TAP5-577
> URL: https://issues.apache.org/jira/browse/TAP5-577
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.0, 5.1.0.1
> Reporter: Andy Blower
> Priority: Critical
> Attachments: T5.1persistentLocale.txt
>
>
> I think that the changes made in T5.1 for TAP5-422 break backwards
> compatibility with T5.0's locale persistence. In T5.0 it was a simple matter
> to override the default cookie persistence by creating a custom
> implementation of the PersistentLocale service and contributing it to be used
> instead of the standard internal T5 implementation.
> The TAP5-422 changes broke backwards compatibility because anyone who's
> created their own implementation of PersistentLocale, or just wants the 5.0
> cookie persistence behaviour, would have found that it's a lot more work and
> involves some heavy changes to Tapestry internals. Now with the recent
> changes for TAP5-418 (committed yesterday), the situation had been alleviated
> somewhat by allowing the the hard-wired URl locale persistence to be switched
> off using a new symbol.
> However, I still think that this breaks backwards compatibility in two ways:
> 1) By changing the default behaviour of locale persistence so that anyone
> relying on the locale persistence behaviour of 5.0 will have to make
> non-trivial changes when they upgrade to 5.1 to keep the same operation.
> 2) By requiring so much work for anyone wanting to keep the 5.0 cookie
> persistence behaviour or define their own custom locale persistence. (In 5.0
> it was easy to figure out and implement a custom locale persistence method)
> From my analysis of the changes made by TAP5-422 & TAP5-418, I think anyone
> wanting non-URL based locale persistence will need to do the following when
> upgrading from 5.0 to 5.1:
> 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false.
> 2) Create an implementation of PersistentLocale and contribute it to the IOC.
> (copied from the standard 5.0 code if the old default cookie persistence is
> desired)
> 3) Create a custom filter written and created to do the same job as the 5.0
> LocalizationFilter and contribute it to the IOC RequestHandler. This filter
> will need to call the LocalizationSetter setLocaleFromLocaleName() method
> instead of the old setThreadLocale() method.
> My suggested resolution would be to re-instate the 5.0 cookie persistence
> (LocalizationFilter & PersistentLocaleImpl) and have the new
> ENCODE_LOCALE_INTO_PATH symbol default to false allowing 5.1 to work the same
> way as 5.0 out of the box. If the symbol is set to true, then the
> LocalizationFilter is disabled (not contributed to RequestHandler) and the
> PersistentLocale service will need to just store the locale (not set it in a
> cookie) for later use by LinkSourceImpl.
> LocalizationSetterImpl.setLocaleFromLocaleName(String localeName) would also
> need changing back to overriding the passed localeName if a persistent one
> had been set into the PersistentLocale service. There may by a much better
> solution than this as I've not spent much time on it, but I though I should
> try to be helpful as possible.
> (It should be noted that this is purely a product of my analysis of the 5.1
> code, I have not found the time to actually run T5.1 and test this out - I
> should be able to do this in about a week and a half, but I'm currently
> approaching a major milestone deadline. Hopefully someone else will find the
> time to prove or disprove my hypothesis.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
