I just dont understand how you expect us to continue helping you if you go and talk trash about something we invest a lot of time in. Based on the slashdot comments you left I dont really understand why you are using wicket at all.
-igor On 8/29/07, Kirk Israel <[EMAIL PROTECTED]> wrote: > > Igor, sorry if I've irritated you. I know some of my frustration comes > from A. an ugly reluctance to embrace change and B. Wicket is doing > great things but it's somewhat early days, and the documentation > (tutorial books and recipe collections) is still scanty. > > Eelco, thanks, your summary was accurate. I thought about a repeater, > it seemed like overkill, and I thought maybe there was a "third > way". (I still have to look into how the encompassing page would feed > the links into the component, maybe not that difficult) > > So am I correct in thinking that, in general, most HTML pages in > WIcket will have all possible subcomponents listed, and the visibility > will control things that shouldn't be there... > > On 8/29/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
