You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Sebastiaan van Erk <se...@sebster.com> on 2009/12/07 08:16:36 UTC
Locale/Style asymmetry
Hi guys,
I have an application with the following url scheme:
http://www.mydomain.com[/brand][/locale]/app[/wicketrelativepath]
The brand and locale parts are optional, and everything after app is the
relative path to the Wicket page. The brand determines the style to use.
The intention is, that if the brand or locale are specified in the URL
they take precedence over any style/locale contained in the session. To
accomplish this I did 3 things:
1) override WicketFilter's getRelativePath()
2) have a filter add style/locale attributes determined from the url to
the http session
3) override getLocale() on my base page class (BasePage) to read as follows:
@Override
public Locale getLocale() {
// Get brand based on the style in the url, or default Brand if the
style is null...
MyBrand brand = MyWebRrequest.get().getBrand();
// First check if there is a required locale (locale in the url).
Locale locale = MyWebRequest.get().getRequiredLocale();
if (locale == null) {
// No required locale, let's see if the current locale is supported.
final Locale currentLocale = super.getLocale();
if (brand.isLocaleSupported(currentLocale)) {
locale = currentLocale;
} else {
// Current locale is not supported, let's see we can use the user's
preferred locale.
final Locale preferredLocale = MyWebRequest.get().getLocale();
if (brand.isLocaleSupported(preferredLocale)) {
locale = preferredLocale;
} else {
// The preferred locale is not supported, use the default locale.
locale = brand.getDefaultLocale();
}
}
}
return locale;
}
This all works fine, for the locale. However, now I run into problems: I
want to do a similar thing for the style.
What I had at the moment was:
public MySession(final MyWebRequest request) {
super(request);
setStyle(request.getBrand().getStyle());
}
Of course this does not work: when you change the url to another brand,
it does not create a new session, so you keep the old brand. So I
thought I'd override the getStyle() method in MySession. However I
can't: Session.getStyle() is final.
Finally, I thought I could override Component.getStyle() to have a
similar logic to the above code, but I can't do that either: Component
does not have a getStyle() method.
So my developer-list question is basically: why is there such an
asymmetry between style and locale? Why isn't there a getStyle() method
on Component, and why is getStyle() on Session final?
My "user-list" question is: how can I achieve what I want?
Regards,
Sebastiaan
Re: Locale/Style asymmetry
Posted by Igor Vaynberg <ig...@gmail.com>.
why not just call session.setstyle() in requestcycle.onbeginrequest()....
-igor
On Sun, Dec 6, 2009 at 11:16 PM, Sebastiaan van Erk <se...@sebster.com> wrote:
> Hi guys,
>
> I have an application with the following url scheme:
>
> http://www.mydomain.com[/brand][/locale]/app[/wicketrelativepath]
>
> The brand and locale parts are optional, and everything after app is the
> relative path to the Wicket page. The brand determines the style to use.
>
> The intention is, that if the brand or locale are specified in the URL they
> take precedence over any style/locale contained in the session. To
> accomplish this I did 3 things:
>
> 1) override WicketFilter's getRelativePath()
> 2) have a filter add style/locale attributes determined from the url to the
> http session
> 3) override getLocale() on my base page class (BasePage) to read as follows:
>
> @Override
> public Locale getLocale() {
> // Get brand based on the style in the url, or default Brand
> if the style is null...
> MyBrand brand = MyWebRrequest.get().getBrand();
> // First check if there is a required locale (locale in the
> url).
> Locale locale = MyWebRequest.get().getRequiredLocale();
> if (locale == null) {
> // No required locale, let's see if the current
> locale is supported.
> final Locale currentLocale = super.getLocale();
> if (brand.isLocaleSupported(currentLocale)) {
> locale = currentLocale;
> } else {
> // Current locale is not supported, let's see
> we can use the user's preferred locale.
> final Locale preferredLocale =
> MyWebRequest.get().getLocale();
> if (brand.isLocaleSupported(preferredLocale))
> {
> locale = preferredLocale;
> } else {
> // The preferred locale is not
> supported, use the default locale.
> locale = brand.getDefaultLocale();
> }
>
> }
> }
> return locale;
> }
>
> This all works fine, for the locale. However, now I run into problems: I
> want to do a similar thing for the style.
>
> What I had at the moment was:
>
> public MySession(final MyWebRequest request) {
> super(request);
> setStyle(request.getBrand().getStyle());
> }
>
> Of course this does not work: when you change the url to another brand, it
> does not create a new session, so you keep the old brand. So I thought I'd
> override the getStyle() method in MySession. However I can't:
> Session.getStyle() is final.
>
> Finally, I thought I could override Component.getStyle() to have a similar
> logic to the above code, but I can't do that either: Component does not have
> a getStyle() method.
>
> So my developer-list question is basically: why is there such an asymmetry
> between style and locale? Why isn't there a getStyle() method on Component,
> and why is getStyle() on Session final?
>
> My "user-list" question is: how can I achieve what I want?
>
> Regards,
> Sebastiaan
>
Re: Locale/Style asymmetry
Posted by Juergen Donnerstag <ju...@gmail.com>.
Component.getStyle() and Component.getVariation() are properly
separated in 1.5. It will not be backported because of the API changes
necessary.
Juergen
On Mon, Dec 7, 2009 at 11:41 AM, Johan Compagner <jc...@gmail.com> wrote:
> In your case dont look at style
> Style is a Session specific thing not component/page
>
> Only use getVariation() that works just like getLocale()
>
>
>
> On Mon, Dec 7, 2009 at 11:16, Sebastiaan van Erk <se...@sebster.com>wrote:
>
>> Hi,
>>
>> I looked into this some more, and I noticed getStyle() does exist on
>> component but it's final. My questions are:
>>
>> 1) Why does the getStyle() logic not mirror the getLocale() logic,
>> specifically:
>> a) why is Component.getStyle() final
>> b) why doesn't Component.getStyle() consult the parent component for
>> the style
>> c) why is Session.getStyle() final (I don't really mind if it is
>> actually, but then why isn't getLocale() final?)
>>
>> 2) How do variations factor into the whole thing? The getStyle() logic of
>> Component seems a bit of a cludge, returning the style + "_" + variation. It
>> seems to me that actually resource lookup interfaces should have an extra
>> parameter for the variation, i.e., for IStringResourceLoader it would
>> become:
>>
>> String loadStringResource(Class<?> clazz, String key, Locale locale,
>> String style, String variation);
>>
>> 3) I checked out Wicket 1.4.x and changed getStyle() to non-final and to
>> follow the logic of Locale (that is, Component.getStyle() consults the
>> parent), and now at everything works for me the way I want it to. The only
>> problem I still have is how to make the code properly take into account
>> variations, since now I just copied the getLocale() method:
>>
>> getStyle() {
>> if (parent != null)
>> {
>> return parent.getStyle();
>> }
>> return getSession().getStyle();
>> }
>>
>> I'm wondering, what is the chance that this functionality somehow enters
>> into Wicket (I prefer not to have to run a patched version)? The problem is,
>> I cannot see any way *without* changing Wicket to make this work, other than
>> just leaving the style null and abusing the variation for what is really the
>> style... (since getVariation() does mirror the getLocale() logic, except
>> that it does not consult the session).
>>
>> Regards,
>> Sebastiaan
>>
>>
>>
>>
>> Sebastiaan van Erk wrote:
>>
>>> Hi guys,
>>>
>>> I have an application with the following url scheme:
>>>
>>> http://www.mydomain.com[/brand][/locale]/app[/wicketrelativepath]
>>>
>>> The brand and locale parts are optional, and everything after app is the
>>> relative path to the Wicket page. The brand determines the style to use.
>>>
>>> The intention is, that if the brand or locale are specified in the URL
>>> they take precedence over any style/locale contained in the session. To
>>> accomplish this I did 3 things:
>>>
>>> 1) override WicketFilter's getRelativePath()
>>> 2) have a filter add style/locale attributes determined from the url to
>>> the http session
>>> 3) override getLocale() on my base page class (BasePage) to read as
>>> follows:
>>>
>>> @Override
>>> public Locale getLocale() {
>>> // Get brand based on the style in the url, or default Brand if the
>>> style is null...
>>> MyBrand brand = MyWebRrequest.get().getBrand();
>>> // First check if there is a required locale (locale in the url).
>>> Locale locale = MyWebRequest.get().getRequiredLocale();
>>> if (locale == null) {
>>> // No required locale, let's see if the current locale is
>>> supported.
>>> final Locale currentLocale = super.getLocale();
>>> if (brand.isLocaleSupported(currentLocale)) {
>>> locale = currentLocale;
>>> } else {
>>> // Current locale is not supported, let's see we can use
>>> the user's preferred locale.
>>> final Locale preferredLocale =
>>> MyWebRequest.get().getLocale();
>>> if (brand.isLocaleSupported(preferredLocale)) {
>>> locale = preferredLocale;
>>> } else {
>>> // The preferred locale is not supported, use the
>>> default locale.
>>> locale = brand.getDefaultLocale();
>>> }
>>>
>>> }
>>> }
>>> return locale;
>>> }
>>>
>>> This all works fine, for the locale. However, now I run into problems: I
>>> want to do a similar thing for the style.
>>>
>>> What I had at the moment was:
>>>
>>> public MySession(final MyWebRequest request) {
>>> super(request);
>>> setStyle(request.getBrand().getStyle());
>>> }
>>>
>>> Of course this does not work: when you change the url to another brand, it
>>> does not create a new session, so you keep the old brand. So I thought I'd
>>> override the getStyle() method in MySession. However I can't:
>>> Session.getStyle() is final.
>>>
>>> Finally, I thought I could override Component.getStyle() to have a similar
>>> logic to the above code, but I can't do that either: Component does not have
>>> a getStyle() method.
>>>
>>> So my developer-list question is basically: why is there such an asymmetry
>>> between style and locale? Why isn't there a getStyle() method on Component,
>>> and why is getStyle() on Session final?
>>>
>>> My "user-list" question is: how can I achieve what I want?
>>>
>>> Regards,
>>> Sebastiaan
>>>
>>
>
Re: Locale/Style asymmetry
Posted by Johan Compagner <jc...@gmail.com>.
In your case dont look at style
Style is a Session specific thing not component/page
Only use getVariation() that works just like getLocale()
On Mon, Dec 7, 2009 at 11:16, Sebastiaan van Erk <se...@sebster.com>wrote:
> Hi,
>
> I looked into this some more, and I noticed getStyle() does exist on
> component but it's final. My questions are:
>
> 1) Why does the getStyle() logic not mirror the getLocale() logic,
> specifically:
> a) why is Component.getStyle() final
> b) why doesn't Component.getStyle() consult the parent component for
> the style
> c) why is Session.getStyle() final (I don't really mind if it is
> actually, but then why isn't getLocale() final?)
>
> 2) How do variations factor into the whole thing? The getStyle() logic of
> Component seems a bit of a cludge, returning the style + "_" + variation. It
> seems to me that actually resource lookup interfaces should have an extra
> parameter for the variation, i.e., for IStringResourceLoader it would
> become:
>
> String loadStringResource(Class<?> clazz, String key, Locale locale,
> String style, String variation);
>
> 3) I checked out Wicket 1.4.x and changed getStyle() to non-final and to
> follow the logic of Locale (that is, Component.getStyle() consults the
> parent), and now at everything works for me the way I want it to. The only
> problem I still have is how to make the code properly take into account
> variations, since now I just copied the getLocale() method:
>
> getStyle() {
> if (parent != null)
> {
> return parent.getStyle();
> }
> return getSession().getStyle();
> }
>
> I'm wondering, what is the chance that this functionality somehow enters
> into Wicket (I prefer not to have to run a patched version)? The problem is,
> I cannot see any way *without* changing Wicket to make this work, other than
> just leaving the style null and abusing the variation for what is really the
> style... (since getVariation() does mirror the getLocale() logic, except
> that it does not consult the session).
>
> Regards,
> Sebastiaan
>
>
>
>
> Sebastiaan van Erk wrote:
>
>> Hi guys,
>>
>> I have an application with the following url scheme:
>>
>> http://www.mydomain.com[/brand][/locale]/app[/wicketrelativepath]
>>
>> The brand and locale parts are optional, and everything after app is the
>> relative path to the Wicket page. The brand determines the style to use.
>>
>> The intention is, that if the brand or locale are specified in the URL
>> they take precedence over any style/locale contained in the session. To
>> accomplish this I did 3 things:
>>
>> 1) override WicketFilter's getRelativePath()
>> 2) have a filter add style/locale attributes determined from the url to
>> the http session
>> 3) override getLocale() on my base page class (BasePage) to read as
>> follows:
>>
>> @Override
>> public Locale getLocale() {
>> // Get brand based on the style in the url, or default Brand if the
>> style is null...
>> MyBrand brand = MyWebRrequest.get().getBrand();
>> // First check if there is a required locale (locale in the url).
>> Locale locale = MyWebRequest.get().getRequiredLocale();
>> if (locale == null) {
>> // No required locale, let's see if the current locale is
>> supported.
>> final Locale currentLocale = super.getLocale();
>> if (brand.isLocaleSupported(currentLocale)) {
>> locale = currentLocale;
>> } else {
>> // Current locale is not supported, let's see we can use
>> the user's preferred locale.
>> final Locale preferredLocale =
>> MyWebRequest.get().getLocale();
>> if (brand.isLocaleSupported(preferredLocale)) {
>> locale = preferredLocale;
>> } else {
>> // The preferred locale is not supported, use the
>> default locale.
>> locale = brand.getDefaultLocale();
>> }
>>
>> }
>> }
>> return locale;
>> }
>>
>> This all works fine, for the locale. However, now I run into problems: I
>> want to do a similar thing for the style.
>>
>> What I had at the moment was:
>>
>> public MySession(final MyWebRequest request) {
>> super(request);
>> setStyle(request.getBrand().getStyle());
>> }
>>
>> Of course this does not work: when you change the url to another brand, it
>> does not create a new session, so you keep the old brand. So I thought I'd
>> override the getStyle() method in MySession. However I can't:
>> Session.getStyle() is final.
>>
>> Finally, I thought I could override Component.getStyle() to have a similar
>> logic to the above code, but I can't do that either: Component does not have
>> a getStyle() method.
>>
>> So my developer-list question is basically: why is there such an asymmetry
>> between style and locale? Why isn't there a getStyle() method on Component,
>> and why is getStyle() on Session final?
>>
>> My "user-list" question is: how can I achieve what I want?
>>
>> Regards,
>> Sebastiaan
>>
>
Re: Locale/Style asymmetry
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
I looked into this some more, and I noticed getStyle() does exist on
component but it's final. My questions are:
1) Why does the getStyle() logic not mirror the getLocale() logic,
specifically:
a) why is Component.getStyle() final
b) why doesn't Component.getStyle() consult the parent component for
the style
c) why is Session.getStyle() final (I don't really mind if it is
actually, but then why isn't getLocale() final?)
2) How do variations factor into the whole thing? The getStyle() logic
of Component seems a bit of a cludge, returning the style + "_" +
variation. It seems to me that actually resource lookup interfaces
should have an extra parameter for the variation, i.e., for
IStringResourceLoader it would become:
String loadStringResource(Class<?> clazz, String key, Locale locale,
String style, String variation);
3) I checked out Wicket 1.4.x and changed getStyle() to non-final and to
follow the logic of Locale (that is, Component.getStyle() consults the
parent), and now at everything works for me the way I want it to. The
only problem I still have is how to make the code properly take into
account variations, since now I just copied the getLocale() method:
getStyle() {
if (parent != null)
{
return parent.getStyle();
}
return getSession().getStyle();
}
I'm wondering, what is the chance that this functionality somehow enters
into Wicket (I prefer not to have to run a patched version)? The problem
is, I cannot see any way *without* changing Wicket to make this work,
other than just leaving the style null and abusing the variation for
what is really the style... (since getVariation() does mirror the
getLocale() logic, except that it does not consult the session).
Regards,
Sebastiaan
Sebastiaan van Erk wrote:
> Hi guys,
>
> I have an application with the following url scheme:
>
> http://www.mydomain.com[/brand][/locale]/app[/wicketrelativepath]
>
> The brand and locale parts are optional, and everything after app is the
> relative path to the Wicket page. The brand determines the style to use.
>
> The intention is, that if the brand or locale are specified in the URL
> they take precedence over any style/locale contained in the session. To
> accomplish this I did 3 things:
>
> 1) override WicketFilter's getRelativePath()
> 2) have a filter add style/locale attributes determined from the url to
> the http session
> 3) override getLocale() on my base page class (BasePage) to read as
> follows:
>
> @Override
> public Locale getLocale() {
> // Get brand based on the style in the url, or default Brand if
> the style is null...
> MyBrand brand = MyWebRrequest.get().getBrand();
> // First check if there is a required locale (locale in the url).
> Locale locale = MyWebRequest.get().getRequiredLocale();
> if (locale == null) {
> // No required locale, let's see if the current locale is
> supported.
> final Locale currentLocale = super.getLocale();
> if (brand.isLocaleSupported(currentLocale)) {
> locale = currentLocale;
> } else {
> // Current locale is not supported, let's see we can use
> the user's preferred locale.
> final Locale preferredLocale =
> MyWebRequest.get().getLocale();
> if (brand.isLocaleSupported(preferredLocale)) {
> locale = preferredLocale;
> } else {
> // The preferred locale is not supported, use the
> default locale.
> locale = brand.getDefaultLocale();
> }
>
> }
> }
> return locale;
> }
>
> This all works fine, for the locale. However, now I run into problems: I
> want to do a similar thing for the style.
>
> What I had at the moment was:
>
> public MySession(final MyWebRequest request) {
> super(request);
> setStyle(request.getBrand().getStyle());
> }
>
> Of course this does not work: when you change the url to another brand,
> it does not create a new session, so you keep the old brand. So I
> thought I'd override the getStyle() method in MySession. However I
> can't: Session.getStyle() is final.
>
> Finally, I thought I could override Component.getStyle() to have a
> similar logic to the above code, but I can't do that either: Component
> does not have a getStyle() method.
>
> So my developer-list question is basically: why is there such an
> asymmetry between style and locale? Why isn't there a getStyle() method
> on Component, and why is getStyle() on Session final?
>
> My "user-list" question is: how can I achieve what I want?
>
> Regards,
> Sebastiaan