You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thorsten Schöning <ts...@am-soft.de> on 2015/01/16 11:50:16 UTC
Proposal: EnclosureGroup to hide surrounding markup depending on enclosure children
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.Schoening@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Proposal: EnclosureGroup to hide surrounding markup depending on enclosure children
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Martin Grigorov,
am Freitag, 16. Januar 2015 um 14:45 schrieben Sie:
> I'd suggest you to take a look at EnclosureContainer.
Hello,
I had and from my understanding that would require me to add more
boilerplate code to manually create such containers and I would still
need to create something like EnclosureGroup as well, because
EnclosureContainer itself works only on one child component.
> 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.
OK, in that case I can still fallback to EnclosureContainer I guess.
Thanks for the hint.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: Thorsten.Schoening@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Proposal: EnclosureGroup to hide surrounding markup depending on
enclosure children
Posted by Martin Grigorov <mg...@apache.org>.
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 <ts...@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.Schoening@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>