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 <[email protected]> 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 <[email protected]>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 >>> >> >
