[jira] Commented: (TAP5-658) Optimizations for custom persistent locale implementations

2009-04-21 Thread Andy Blower (JIRA)

[ 
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

2009-04-20 Thread Howard M. Lewis Ship (JIRA)

[ 
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

2009-04-20 Thread Howard M. Lewis Ship (JIRA)

[ 
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.