Good, this suggests that having a Panel as a boilerplate and then turning off the parts that are not required is a recognised pattern. Otherwise I could foresee the proliferation of home made components reaching a point where it became a burden to know which one to use.
On Wed, Apr 9, 2008 at 7:57 AM, John Patterson <[EMAIL PROTECTED]> wrote: > > You would also need to setVisible(false) on the WMC or wicket would throw > an > exception at the missing child components. I use a simple class > InvisibleComponent for this. > > > Eric Rotick wrote: > > > > 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> > > > > > > > > > > </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> > >> > > > >> > > > >> > > > >> > > </wicket:panel> > >> > > > >> > > <wicket:panel> > >> > > > >> > > > >> > > > >> > > > >> > > </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] > >> > > >> > > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Question-on-component-hierarchy-tp16567888p16580692.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
