Hi, We use different approach than styles and variations. We have GenericPage with following definition: public abstract class GenericPage<K extends Serializable> extends EntityPage<K> implements IMarkupResourceStreamProvider, IMarkupCacheKeyProvider
Then in public IResourceStream getMarkupResourceStream(final MarkupContainer container, java.lang.Class<?> containerClass) we can substite any required "design" of the page dynamically, for example we have: "XXXWebApplication.get().getDesignSupplier().getDesign()" Also, all our pages are inherited from GenericPage. By the way that's give us interesting feature: we can have pages for viewing/editing "common entities" like User/Page/MenuItem/Category and etc. But later simply include that pages into design of new site by "returning" in getDesign() required design for this particular site. So we have "generic JAR" with all core related things: entities/view and edit page and etc: and we don't need to introduce changes for common pages in any particular project which use this "generic JAR". Thanks, Ilia 2013/5/6 Martin Grigorov <[email protected]> > Hi, > > You can use variations instead. > Each special page can override #getVariation(). > > > On Fri, May 3, 2013 at 7:27 PM, Allen Gilbert <[email protected] > >wrote: > > > If locale and/or style are determined by a user-configurable setting, > > then yes, I agree that all pages should be affected by it. However, > > we're trying to differentiate styles between pages viewed within the > > same session. I'm guessing that Session.style was designed to be set > > once, not dynamically... > > > > On Fri, May 3, 2013 at 11:55 AM, Paul Bors <[email protected]> wrote: > > > But isn't that normal behavior? > > > > > > Consider localization alone and setting the user's language in a > session. > > > If the user logs in and uses English and then opens a new tab (same > > session) > > > and choose Spanish, going back to the first tab and refreshing the page > > > should be in Spanish. > > > > > > Same for you. What you need to do is create a new session for the > second > > tab > > > in order to treat them separate. > > > > > > ~ Thank you, > > > Paul Bors > > > > > > -----Original Message----- > > > From: Allen Gilbert [mailto:[email protected]] > > > Sent: Friday, May 03, 2013 12:48 PM > > > To: users > > > Subject: Dynamic Session.style > > > > > > We are adding some new pages to our application that we'd like to style > > > differently from existing ones. We also want to reuse Panels we've > > built, so > > > we're employing the Style mechanism outlined in > > > > > > https://cwiki.apache.org/confluence/display/WICKET/Localization+and+Skinning > > > +of+Applications. > > > > > > We have two different base pages for the separate styles, and in each > > base > > > page constructor, we set the proper Session.style. This works fine, but > > > doesn't seem like the best approach, and now we've discovered a problem > > with > > > it. > > > > > > Say a user lands on page A with style A (the default style), then opens > > page > > > B with style B in a new tab. After looking at page B for a bit, the > user > > > goes back to the tab with page A. The user clicks an AjaxLink that > should > > > display an InfoPanel. InfoPanel can be used with both styles, so it has > > two > > > markup files: InfoPanel.html, and InfoPanel_B.html. Unfortunately, > > because > > > page B was the last page to set Session.style, InfoPanel_B.html is > > loaded, > > > even though the user is on page A. > > > > > > Any suggestions on how to solve this problem? The first thing that came > > to > > > my mind was to create an AbstractRequestCycleListener subclass that > could > > > properly set Session.style for each request, but I'm not sure if > that's a > > > good idea. > > > > > > Thanks for your help! > > > > > > -Allen > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > -- > Martin Grigorov > Wicket Training & Consulting > http://jWeekend.com <http://jweekend.com/> >
