I thought I understood the component hierarchy but then I started to tell the guys about it and now I'm not so sure.
If the markup defines a hierarchy as A contains B contains C, in effect, this means that C is added to B which is added to A. If we expand B to be more complex we can use maybe a Panel which we identify as B but inside it is BA , BB and so on. So, all the time there is a direct relationship between the wicket identified tags in the markup and the components in the code. Now we introduce a repeater of some kind and it appears that the component hierarchy is broken but it's not. So if C was a repeater and it had 4 children then the hierarchy is still A to B to C but within C there is C to C1, C to C2 and so on. Now, if we need to have a runtime variable amount of markup which is variable, not in terms of the same markup repeated but completely different markup based on some logic then we might define a Panel which handles the variation. This is fine but what if the contents of the Panel is also variable. In this case further Panels are needed until the variable requirements are covered. Now the rub; although there are components, such as WebMarkupContainer which can be used to group components, the use of any component which is not 'transparent' must have the related wicket:id in some markup somewhere. So, lets take an example where we have a list of items which can be just text or a link which has an optional image. It seems that I have to define panels for :- - wrapper panel for the list - a link with it's text - a link with it's text and image So we have markup such as <wicket:panel> <ul> <li wicket:id="items"/> </ul> </wicket:panel> <wicket:panel> <span wicket:id="link"> <span wicket:id="text"/> </span> </wicket:panel> <wicket:panel> <span wicket:id="link"> <span wicket:id="text"/> <img wicket:id="image"/> </span> </wicket:panel> Have I got this correct or have I gone astray somewhere?
