So let me try to rephrase your problem: you have a header component that shows a variable number of components (links). Use a repeater (e.g. list view or repeating view) for the variable number of components, and you probably want to wrap the header component in a panel so that it is easy to move it around, place it on other pages, etc. Think a bit about whether those links should be internal or to bookmarkable pages, and that should do the trick, right?
Eelco On 8/29/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > Hey there-- > So I came up with a solution to this, but I suspect it's not very > Wicket-y, so I'd like some suggestions on best practices: > > We want a header component that can go on different pages, with 1 2 or > 3 links to other pages. > (Well, I guess ideally any #, but with my approach it was easier to > match it to the maximum shown in the spec). Visually, the end result > would be > > Back to: _LINK1_, _LINK2_ or _LINK3_ > > As far as i can tell, the links and their labels should be created by > the page containing the component. The trouble is, since the HTML and > wicket:id for displaying each link is in the HTML for the component, > the page has to "know" what ID to assign its link (and it doesn't > seem like you can change the id of a component object after its > created, which would have meant the page could just hand a list of > un-ID'd labeled links in, and the component could have re-IDed them to > match the HTML) > > So the component has a static callback getIdPrefixForLink() and > getIdPrefixForLinkLabel(), and the page uses that, and then uses that > string + 0, 1, or 2 for the links its making and handing to the > constructor of the Header component. > > So if the Component only gets 1 Labeled Link, it then creates > placeholder objects for the other 2, to make sure the hierarchy as > outlined in the HTML is still ok, and then just hides them. > > And there's a tad more logic for the commas and the "or". > > So, this all seems really hacky to me. What's a better way? In other > words: Is having to make place holders for everything that ever MIGHT > appear on a page or component, and then making them invisible when you > don't need them, the Wicket way, or is there something more direct? > And/or is there a standard way of letting parent pages or component > make subsubcomponents to be added to a subcomponent (e.g the Page > making PageLinks to be added to the Header component -- incidentally I > can't just pass in a reference to the class, because of what we had to > do to make "lazy loading" links that don't fully instantiate the page > they go to until that link is clicked.) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
