You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Paul Benedict <pa...@yahoo.com> on 2006/06/30 19:53:47 UTC
Localization Bridge (was Re: Thoughts on 1.3.x)
Joe Germuska <Jo...@Germuska.com> wrote:That said, I don't think you should not do the work you describe,
just because you may have to leave the Localizer (or whatever you
call it) in the ServletContext under a well known key. It's just
that it feels so outdated!
Here's my solution. Unless anyone feels strongly about it, I am going to open up a ticket and submit my patch.
1) I am going to retain the Globals.LOCAL_KEY as the constant for session-strategy localization. Previous applications will continue using this without a problem.
2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an object that implements these methods:
Locale resolveLocale(HttpServletRequest request);
void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale);
These methods will not be of any interface. The resolver object can be any class which implements those two methods, and I will use BeanUtils to retrieve them. The reason I am choosing this design over an interface is because I want to plug in implementations from any framework (like Struts2 or Spring) without requiring an adapter interface. At most, the adapter interface would be just a pass-through and so it has questionable value.
3) Modify RequestUtils.getUserLocale to lookup the stategy first and use it. RequestUtils will have a pre-built strategy for doing session look-up, to implement requirement #1 (see above).
4) Modify Action.get/setLocale to delegate to the locale strategy. The retrieval of the strategy will most likely be in RequestUtils.
If this works right, I should be able to punch to bridge Struts 1, Struts 2, and Spring all behind the scenes. For those developing Struts 2, do you have any class which comes close to the above? I'd like to coordinate with you so that Struts1-Struts2 apps can bridge localization in the 2.0.0 release.
I am targetting 1.3.6+
Paul
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Ted Husted <hu...@apache.org>.
On 6/30/06, Alexandru Popescu <th...@gmail.com> wrote:
> I am not sure I understand this proposal. As far as I know this is
> already supported by WW and quite nicely. So, why would we want to add
> just another dependency?
Well,
Naill asked if Clintoo did anything that Struts 2 didn't already do well.
Jason said "Nope, we're good."
Then, the chat turned to whether we should use it with Struts 1,
because s1 doesn't do everything s2 or Clintoo can do in terms of
locale resolution. And, if we used it for s1 (the logic went) should
we use it for s2?
At which point, Ted and Alex said, "s2 ain't broke."
My suggestion would be that if we want to do something different or
better with the Struts 1 locale resolution, then we should look
inhouse to s2 first, before (as Jason said) adopting someone else's
1.0 release.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Alexandru Popescu <th...@gmail.com>.
I am not sure I understand this proposal. As far as I know this is
already supported by WW and quite nicely. So, why would we want to add
just another dependency?
./alex
--
.w( the_mindstorm )p.
---
(http://themindstorms.blogspot.com)
On 6/30/06, Don Brown <mr...@twdata.org> wrote:
> If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to
> adopt it as well, as it would make migration easier, and reduce the number of
> differences between the two versions. I'd like to take that approach with other
> areas like validation and annotations in the future.
>
> Don
>
> Niall Pemberton wrote:
> > On 6/30/06, Paul Benedict <pa...@yahoo.com> wrote:
> >> Joe Germuska <Jo...@Germuska.com> wrote:That said, I don't think you
> >> should not do the work you describe,
> >> just because you may have to leave the Localizer (or whatever you
> >> call it) in the ServletContext under a well known key. It's just
> >> that it feels so outdated!
> >>
> >> Here's my solution. Unless anyone feels strongly about it, I am going
> >> to open up a ticket and submit my patch.
> >>
> >> 1) I am going to retain the Globals.LOCAL_KEY as the constant for
> >> session-strategy localization. Previous applications will continue
> >> using this without a problem.
> >>
> >> 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an
> >> object that implements these methods:
> >>
> >> Locale resolveLocale(HttpServletRequest request);
> >>
> >>
> >> void setLocale(HttpServletRequest request, HttpServletResponse
> >> response, Locale locale);
> >>
> >>
> >> These methods will not be of any interface. The resolver object can be
> >> any class which implements those two methods, and I will use BeanUtils
> >> to retrieve them. The reason I am choosing this design over an
> >> interface is because I want to plug in implementations from any
> >> framework (like Struts2 or Spring) without requiring an adapter
> >> interface. At most, the adapter interface would be just a pass-through
> >> and so it has questionable value.
> >>
> >> 3) Modify RequestUtils.getUserLocale to lookup the stategy first and
> >> use it. RequestUtils will have a pre-built strategy for doing session
> >> look-up, to implement requirement #1 (see above).
> >>
> >> 4) Modify Action.get/setLocale to delegate to the locale strategy. The
> >> retrieval of the strategy will most likely be in RequestUtils.
> >>
> >> If this works right, I should be able to punch to bridge Struts 1,
> >> Struts 2, and Spring all behind the scenes. For those developing
> >> Struts 2, do you have any class which comes close to the above? I'd
> >> like to coordinate with you so that Struts1-Struts2 apps can bridge
> >> localization in the 2.0.0 release.
> >
> > I had a quick peek at Cintoo messages today (Apache 2 license) -
> > initial impression was its a nice implementation for i18n. They use
> > ThreadLocale to store the Locale which makes it available everywhere.
> > I believe that approach has been used by the ww guys and from memory I
> > think there are similar concepts for configuring resources
> > (packaging). It would interesting to hear one of the WW guys if they
> > had time to look at it. Perhaps we can use it to do the job Commons
> > Resources was intended for.
> >
> > Anyway I digress, this would be one way of making Locale available all
> > over the place (messages, validation, tiles) without necessarily
> > changing the API.
> >
> > http://messages.cintoo.org/
> > http://www.theserverside.com/news/thread.tss?thread_id=41116
> > http://www.infoq.com/news/Cintoo-Messages-1.0-i18n
> >
> > Niall
> >
> > P.S. don't look at the cintoo site using IE - its a mess - OK in firefox
> > though.
> >
> >> I am targetting 1.3.6+
> >>
> >> Paul
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Ted Husted <hu...@apache.org>.
I created a ticket for this thread, so that we can pick it up after 1.3.5.
* http://issues.apache.org/struts/browse/STR-2897
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Martin Cooper <ma...@apache.org>.
On 6/30/06, Paul Benedict <pa...@yahoo.com> wrote:
>
> What does Clintoo do that standard ThreadLocal cannot? I am trying to
> understand the benefit here of this package.
For one thing, it introduces funky syntax that I personally dislike. ;-)
Using '$' and '_' as method names isn't my idea of clarity in programming.
--
Martin Cooper
Ted Husted <hu...@apache.org> wrote: Yes, but we should let one framework
> go first, and prove something
> works in practices, before adopting something new in both
>
> On 6/30/06, Don Brown wrote:
> > If Struts 1 decided to go with Cintoo, I think it would be good for
> Struts 2 to
> > adopt it as well, as it would make migration easier, and reduce the
> number of
> > differences between the two versions. I'd like to take that approach
> with other
> > areas like validation and annotations in the future.
>
> I might amend that to say if Struts 1 decides to go with Cllntoo, and
> we ship a stable release or two with Clintoo, and we decide we really
> like Cintoo, then, sure, we would want to consider it for Struts 2.x
> as well. But, there's no reason to rush both frameworks to judgment.
>
> Of course, we should try to stablize the feature set between s1 and
> s2. We added wildcards to s2, and I'm sure we will find some other
> things to add next month too.
>
> At the same time, we should look for things we can backport to s1. One
> thing Michael mentioned on the rough spots page was better POJO
> support for s1.
>
> * http://wiki.apache.org/struts/SAF1RoughSpots
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
> ---------------------------------
> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
>
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Paul Benedict <pa...@yahoo.com>.
What does Clintoo do that standard ThreadLocal cannot? I am trying to understand the benefit here of this package.
Ted Husted <hu...@apache.org> wrote: Yes, but we should let one framework go first, and prove something
works in practices, before adopting something new in both
On 6/30/06, Don Brown wrote:
> If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to
> adopt it as well, as it would make migration easier, and reduce the number of
> differences between the two versions. I'd like to take that approach with other
> areas like validation and annotations in the future.
I might amend that to say if Struts 1 decides to go with Cllntoo, and
we ship a stable release or two with Clintoo, and we decide we really
like Cintoo, then, sure, we would want to consider it for Struts 2.x
as well. But, there's no reason to rush both frameworks to judgment.
Of course, we should try to stablize the feature set between s1 and
s2. We added wildcards to s2, and I'm sure we will find some other
things to add next month too.
At the same time, we should look for things we can backport to s1. One
thing Michael mentioned on the rough spots page was better POJO
support for s1.
* http://wiki.apache.org/struts/SAF1RoughSpots
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------
How low will we go? Check out Yahoo! MessengerÂ’s low PC-to-Phone call rates.
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Ted Husted <hu...@apache.org>.
Yes, but we should let one framework go first, and prove something
works in practices, before adopting something new in both
On 6/30/06, Don Brown <mr...@twdata.org> wrote:
> If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to
> adopt it as well, as it would make migration easier, and reduce the number of
> differences between the two versions. I'd like to take that approach with other
> areas like validation and annotations in the future.
I might amend that to say if Struts 1 decides to go with Cllntoo, and
we ship a stable release or two with Clintoo, and we decide we really
like Cintoo, then, sure, we would want to consider it for Struts 2.x
as well. But, there's no reason to rush both frameworks to judgment.
Of course, we should try to stablize the feature set between s1 and
s2. We added wildcards to s2, and I'm sure we will find some other
things to add next month too.
At the same time, we should look for things we can backport to s1. One
thing Michael mentioned on the rough spots page was better POJO
support for s1.
* http://wiki.apache.org/struts/SAF1RoughSpots
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Don Brown <mr...@twdata.org>.
If Struts 1 decided to go with Cintoo, I think it would be good for Struts 2 to
adopt it as well, as it would make migration easier, and reduce the number of
differences between the two versions. I'd like to take that approach with other
areas like validation and annotations in the future.
Don
Niall Pemberton wrote:
> On 6/30/06, Paul Benedict <pa...@yahoo.com> wrote:
>> Joe Germuska <Jo...@Germuska.com> wrote:That said, I don't think you
>> should not do the work you describe,
>> just because you may have to leave the Localizer (or whatever you
>> call it) in the ServletContext under a well known key. It's just
>> that it feels so outdated!
>>
>> Here's my solution. Unless anyone feels strongly about it, I am going
>> to open up a ticket and submit my patch.
>>
>> 1) I am going to retain the Globals.LOCAL_KEY as the constant for
>> session-strategy localization. Previous applications will continue
>> using this without a problem.
>>
>> 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an
>> object that implements these methods:
>>
>> Locale resolveLocale(HttpServletRequest request);
>>
>>
>> void setLocale(HttpServletRequest request, HttpServletResponse
>> response, Locale locale);
>>
>>
>> These methods will not be of any interface. The resolver object can be
>> any class which implements those two methods, and I will use BeanUtils
>> to retrieve them. The reason I am choosing this design over an
>> interface is because I want to plug in implementations from any
>> framework (like Struts2 or Spring) without requiring an adapter
>> interface. At most, the adapter interface would be just a pass-through
>> and so it has questionable value.
>>
>> 3) Modify RequestUtils.getUserLocale to lookup the stategy first and
>> use it. RequestUtils will have a pre-built strategy for doing session
>> look-up, to implement requirement #1 (see above).
>>
>> 4) Modify Action.get/setLocale to delegate to the locale strategy. The
>> retrieval of the strategy will most likely be in RequestUtils.
>>
>> If this works right, I should be able to punch to bridge Struts 1,
>> Struts 2, and Spring all behind the scenes. For those developing
>> Struts 2, do you have any class which comes close to the above? I'd
>> like to coordinate with you so that Struts1-Struts2 apps can bridge
>> localization in the 2.0.0 release.
>
> I had a quick peek at Cintoo messages today (Apache 2 license) -
> initial impression was its a nice implementation for i18n. They use
> ThreadLocale to store the Locale which makes it available everywhere.
> I believe that approach has been used by the ww guys and from memory I
> think there are similar concepts for configuring resources
> (packaging). It would interesting to hear one of the WW guys if they
> had time to look at it. Perhaps we can use it to do the job Commons
> Resources was intended for.
>
> Anyway I digress, this would be one way of making Locale available all
> over the place (messages, validation, tiles) without necessarily
> changing the API.
>
> http://messages.cintoo.org/
> http://www.theserverside.com/news/thread.tss?thread_id=41116
> http://www.infoq.com/news/Cintoo-Messages-1.0-i18n
>
> Niall
>
> P.S. don't look at the cintoo site using IE - its a mess - OK in firefox
> though.
>
>> I am targetting 1.3.6+
>>
>> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Localization Bridge (was Re: Thoughts on 1.3.x)
Posted by Niall Pemberton <ni...@gmail.com>.
On 6/30/06, Paul Benedict <pa...@yahoo.com> wrote:
> Joe Germuska <Jo...@Germuska.com> wrote:That said, I don't think you should not do the work you describe,
> just because you may have to leave the Localizer (or whatever you
> call it) in the ServletContext under a well known key. It's just
> that it feels so outdated!
>
> Here's my solution. Unless anyone feels strongly about it, I am going to open up a ticket and submit my patch.
>
> 1) I am going to retain the Globals.LOCAL_KEY as the constant for session-strategy localization. Previous applications will continue using this without a problem.
>
> 2) I am going to add a LOCAL_RESOLVER_KEY constant which returns an object that implements these methods:
>
> Locale resolveLocale(HttpServletRequest request);
>
>
> void setLocale(HttpServletRequest request, HttpServletResponse response, Locale locale);
>
>
> These methods will not be of any interface. The resolver object can be any class which implements those two methods, and I will use BeanUtils to retrieve them. The reason I am choosing this design over an interface is because I want to plug in implementations from any framework (like Struts2 or Spring) without requiring an adapter interface. At most, the adapter interface would be just a pass-through and so it has questionable value.
>
> 3) Modify RequestUtils.getUserLocale to lookup the stategy first and use it. RequestUtils will have a pre-built strategy for doing session look-up, to implement requirement #1 (see above).
>
> 4) Modify Action.get/setLocale to delegate to the locale strategy. The retrieval of the strategy will most likely be in RequestUtils.
>
> If this works right, I should be able to punch to bridge Struts 1, Struts 2, and Spring all behind the scenes. For those developing Struts 2, do you have any class which comes close to the above? I'd like to coordinate with you so that Struts1-Struts2 apps can bridge localization in the 2.0.0 release.
I had a quick peek at Cintoo messages today (Apache 2 license) -
initial impression was its a nice implementation for i18n. They use
ThreadLocale to store the Locale which makes it available everywhere.
I believe that approach has been used by the ww guys and from memory I
think there are similar concepts for configuring resources
(packaging). It would interesting to hear one of the WW guys if they
had time to look at it. Perhaps we can use it to do the job Commons
Resources was intended for.
Anyway I digress, this would be one way of making Locale available all
over the place (messages, validation, tiles) without necessarily
changing the API.
http://messages.cintoo.org/
http://www.theserverside.com/news/thread.tss?thread_id=41116
http://www.infoq.com/news/Cintoo-Messages-1.0-i18n
Niall
P.S. don't look at the cintoo site using IE - its a mess - OK in firefox though.
> I am targetting 1.3.6+
>
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org