or just write something in perl and call it a day. -igor
On 8/29/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > 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] > >
