Hi, I'd suggest you to take a look at EnclosureContainer. It is very simple component that is much more reliable than <wicket:enclosure> and <div wicket:enclosure="">. There are many known problems with <wicket:enclosure> (consult with JIRA about them) so I guess you will face issues with your custom solution at some point too.
Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Jan 16, 2015 at 12:50 PM, Thorsten Schöning <tschoen...@am-soft.de> wrote: > Hi all, > > I have a navigation, where each level consists of a headline to > summarize all sub nav links and a list of those sub nav links. Pretty > standard. I needed to implement two things: First the sub nav links > itself should be hidden or visible during some configuration and such > on runtime, e.g. if a user is logged in and has special permissions to > see the link etc. Second if all sub nav links are invisible, their > headline should be invisible, too, which results in the whole HTML of > that navigation block should be removed at all. > > Hiding the links itself is pretty straightforward by using > wicket:enclosure, because the links are the only wicket objects within > and everything works automatically. The trickier part is to hide the > whole parent HTML with the headline, if all links are hidden already. > > This sounded like a perfect approach for wicket:enclosure to me as > well, but from my understanding wouldn't work because enclosure always > needs a special child component to work on, only one of that and is > transparent in the component hierarchy and so on. The only > alternatives I found were using wicket:container[1], but from my > understanding that approach would require to manually create such an > container, something which I wanted to avoid, simply because I > wouldn't need it for any other useful reason. > > So what I did was to have a closer look at the current > EnclosureHandler and Enclosure and implement my own EnclosureGroup > based on those. Such a group is only a simple component which combines > Enclosures as children to determine the visibility of the whole group > depending on the visibility of the children. Because I as well > implemented a filter for the MarkupParser, I'm able to determine > special combinations where "wicket:enclosure" tags can't be standard > tags anymore, but need to be my new EnclosureGroup and can be resolved > automatically like the standard wicket:enclosure. The only thing I > needed to change from Wickets default behavior was the usage of > EnclosureHandler as a component resolver and instead replace it with > my own EnclosureGroupHandler, simply because naked wicket:enclosure > without child attribute is not accepted by Wicket, but I use those as > my group indicator. > > Here's one example: > > > <ol class="subNav"> > > <wicket:enclosure> > > <li class="cmds"> > > <h2> > > <wicket:message > key="...">...</wicket:message> > > </h2> > > <ol class="subNav"> > > <wicket:enclosure> > > <li class="..."> > > <a href="..." > > title="..." > > wicket:id="..." > > > wicket:message="..."> > > <wicket:message > key="...">...</wicket:message> > > </a> > > </li> > > </wicket:enclosure> > > </ol> > > </li> > > </wicket:enclosure> > > <wicket:enclosure> > > [...] > > </wicket:enclosure> > > </ol> > > My simple rule is that each wicket:enclosure without any child > attribute, but with wicket:enclosure as children is my new group. My > current implementation seems to work, but I still have some question: > > Do you see any likely problems with such an approach, which I just > didn't run into yet? > > Do you see any easier alternatives I've not recognized and which don't > force me to manually create components? > > If my approach doesn't totally suck and you find it useful, is there > any interest to add it to the wicket core? From my opinion others > could benefit of it as well. > > [1] > http://stackoverflow.com/questions/11754719/wicket-container-that-is-hidden-when-all-its-child-components-are-hidden > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
