Override MarkupContainer.add()? It's final, so I can't... On Thu, Nov 3, 2011 at 4:46 PM, Igor Vaynberg <[email protected]> wrote: > override add() and funnel everything into a non-transparent > webmarkupcontainer. > > -igor > > On Thu, Nov 3, 2011 at 2:40 PM, Allen Gilbert <[email protected]> wrote: >> Hello, >> >> I've defined an abstract subclass of WebPage (BasePage) that knows >> whether or not a user can access the content of any concrete page. If >> a user does not have access, I don't want to block them from landing >> on the page; instead, I'd like to show some page-specific content >> instructing them how they can gain access to it. The structure of >> that content is the same across all of my pages, so I'd like BasePage >> to a) define the markup necessary to display it, and b) hide its >> subclass's content when necessary. I came up with the following >> approach, defining childContent as a transparent resolver: >> >> BasePage.html >> ... >> <div wicket:id="childContent"> >> <wicket:child /> >> </div> >> ... >> >> BasePage.java >> ... >> WebMarkupContainer childContent = new WebMarkupContainer("childContent") { >> @Override >> public boolean isTransparentResolver() { >> return true; >> } >> }; >> childContent.setVisible(isAccessible); >> add(childContent); >> ... >> >> Although this works, I have run into problems related to the >> transparent resolver (e.g. >> http://wicket-users.markmail.org/search/?q=#query:+page:1+mid:3gmjcjrggaxdrek2+state:results). >> The only other approach I can think of is to add code to each >> BasePage subclass that will hide its components when isAccessible is >> false, but that seems fairly redundant. Any other ideas? Aside from >> defining a transparent resolver (not recommended, and apparently >> removed in 1.5), is there a design flaw to this approach? >> >> I'm using Wicket 1.4.18. >> >> 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]
