One more thing that was suggested in class. Is it possible to define a Panel which had all suitable and appropriate sub components and then to no-op the ones that were not needed?
So in the earlier example there could be a panel <wicket:panel> <span wicket:id="link"> <span wicket:id="text"/> <img wicket:id="image"/> </span> </wicket:panel> and if the image was not needed it could be no-op'ed out by defining a WebMarkupContainer but with no children. On Tue, Apr 8, 2008 at 6:53 PM, Eric Rotick <[EMAIL PROTECTED]> wrote: > Many thanks for the clarification. > > As I am about to start teaching the rudiments of Wicket to a project team > I guess the teacher should know what they are talking about. > > > On Tue, Apr 8, 2008 at 6:50 PM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > > > you dont need a panel for the repeater itself. as for variable > > component hierarchy inside the repeater itself, you are correct: you > > have to either use a panel or a fragment. > > > > -igor > > > > > > On Tue, Apr 8, 2008 at 9:37 AM, Eric Rotick <[EMAIL PROTECTED]> > > wrote: > > > 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? > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
