[jira] Commented: (TAP5-658) Optimizations for custom persistent locale implementations
[ https://issues.apache.org/jira/browse/TAP5-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701141#action_12701141 ] Andy Blower commented on TAP5-658: -- You're correct about the calls to PersistentLocale.set() - I have no idea why I thought it was being called for every request, it's not. I do think that the symbol could be used to stop the checks for supported locale being the first part of a URL. It's never going to be if ENCODE_LOCALE_INTO_PATH is false. Regarding LocalizationSetter, I have not rewritten CELE to handle locales, and I actually decided against doing it for our URL manipulation too - I advised the service instead which worked very nicely. (shame I couldn't just have decorated a service for 5.0 but that did it in the dispatcher...) It seems you're still conflating these two *separate* aspects of my Tapestry work: * URL manipulation, where I did mess with internals in 5.0 with full knowledge of the implications. (took less than a day to move this code to advice in T5.1, no problem at all once I figured out the best approach) * Overriding locale persistence, where I did not touch the internals and there is still a backwards compatibility issue that seems to bother no one so it's pretty irrelevant. So, what I've actually done to handle locales my own way in T5.1 is to follow the three steps from TAP5-577. 1) Set the ENCODE_LOCALE_INTO_PATH symbol to false. 2) Created an implementation of PersistentLocale and contribute it to the IOC. (same as 5.0 version we had) 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. I attached the relevant changes to our module for step 3 to TAP5-577, I don't know if you've seen that. If you take a look you can see that Locale is converted to a string just so it can be passed. I could add the functionality from LocalizationSetter to the LocalizationFilter I had to create, but that seems wrong if I've not rewritten CELE for locale functionality or anything else. I certainly could add the functionality into LocalizationFilter but that seems to be almost like if you don't want URL locales then you need to implement it all yourself which is anti-tapestry ethos I would have thought. > Optimizations for custom persistent locale implementations > -- > > Key: TAP5-658 > URL: https://issues.apache.org/jira/browse/TAP5-658 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.4 >Reporter: Andy Blower >Priority: Minor > > I was wondering if having a method in LocalizationSetter that allows a Locale > to be passed would be a good idea. This would remove the conversion to String > and back again which occurs for every request if you are actually storing a > locale with a custom persistent locale implementation. > The other slight annoyance I have with this area of T5 is that > PersistentLocale.set() being constantly called by the LocalizationSetter for > each request, this doesn't fit in with the old way that the PersistentLocale > service was used. I think that only executing persistentLocale.set(locale); > (line 113) if ENCODE_LOCALE_INTO_PATH is true would be a nice little > improvement/optimization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-658) Optimizations for custom persistent locale implementations
[ https://issues.apache.org/jira/browse/TAP5-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700983#action_12700983 ] Howard M. Lewis Ship commented on TAP5-658: --- W.R.T. the remainder of this request: if you have rewritten CELE to handle locales your own way, you probably don't need LocalizationSetter anyway: outside of some parsing and validation, it invokes ThreadLocale.setLocale() and maybe PersistentLocale.set(). You code, in your presumed replacement CELE, can do that directly. > Optimizations for custom persistent locale implementations > -- > > Key: TAP5-658 > URL: https://issues.apache.org/jira/browse/TAP5-658 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.4 >Reporter: Andy Blower >Priority: Minor > > I was wondering if having a method in LocalizationSetter that allows a Locale > to be passed would be a good idea. This would remove the conversion to String > and back again which occurs for every request if you are actually storing a > locale with a custom persistent locale implementation. > The other slight annoyance I have with this area of T5 is that > PersistentLocale.set() being constantly called by the LocalizationSetter for > each request, this doesn't fit in with the old way that the PersistentLocale > service was used. I think that only executing persistentLocale.set(locale); > (line 113) if ENCODE_LOCALE_INTO_PATH is true would be a nice little > improvement/optimization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-658) Optimizations for custom persistent locale implementations
[ https://issues.apache.org/jira/browse/TAP5-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700982#action_12700982 ] Howard M. Lewis Ship commented on TAP5-658: --- PersistentLocale.set() now gets invoked when the request dispatching logic (mostly inside ComponentEventLinkEncoder) identifies that a locale was specified inside the request. Setting this value is meaningful later in the request if any links are rendered, as the locale will be encoded into the URL by CELE (or its override). This can be in the path itself, as a cookie, or as a query parameter. So the definition of how PersistentLocale is used shifted a bit between releases. I would have considered deprecating the interface and creating a new one with a different name except that PersistentLocale.set() is the way to programattically select a new persistent locale in both 5.0 and 5.1 and that was, practically speaking, the key bit of API that needed to stay consistent between releases. > Optimizations for custom persistent locale implementations > -- > > Key: TAP5-658 > URL: https://issues.apache.org/jira/browse/TAP5-658 > Project: Tapestry 5 > Issue Type: Improvement > Components: tapestry-core >Affects Versions: 5.1.0.4 >Reporter: Andy Blower >Priority: Minor > > I was wondering if having a method in LocalizationSetter that allows a Locale > to be passed would be a good idea. This would remove the conversion to String > and back again which occurs for every request if you are actually storing a > locale with a custom persistent locale implementation. > The other slight annoyance I have with this area of T5 is that > PersistentLocale.set() being constantly called by the LocalizationSetter for > each request, this doesn't fit in with the old way that the PersistentLocale > service was used. I think that only executing persistentLocale.set(locale); > (line 113) if ENCODE_LOCALE_INTO_PATH is true would be a nice little > improvement/optimization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
