interface menuitem extends serializable { imodel getlabel(); abstract void
onclick(); }
class basepage extends webpage {
protected abstract list<menuitem> getitems();
public basepage() {
add(new listview("menu", new propertymodel(this, "items")) {
populateitems(item item) {
menuitem mi=item.getmodelobject();
link link=new link("link", item.getmodel()) {
onclick() { ((menuitem)getmodelobject()).onclick(); }
}
item.add(link);
link.add(new label("label", mi.getlabel());
}
}
}
<ul><li wicket:id="menu"><a wicket:id="link"><span
wicket:id="label"></span></a></li></ul>
-igor
On 8/30/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
>
> Igor, I'm sorry I've sounded unappreciative to the work the team is doing.
>
> Yes, I'm a dumb curmudgeon who is having a lot of problems adjusting
> to a new approach to things, and who, despite an honest effort to
> embrace the wicket outlook, may have stumbled, and also dove right in
> to the code base we started here with not enough in-depth reading of
> "Pro Wicket" and fiddling around with more toy examples.... and then
> after that, started to get childishly frustrated when things didn't go
> the way I expected. On slashdot I'm more inclined to state my biases
> in an extreme way, in part to get some counterargument -- and there
> actually ended up being some good counterargument there, some wicket
> fans who expressed how much they dig the approach. My team has decided
> on wicket as the extensible, page centric approach to the fairly
> complex app we have to write, and so far I've done a poor job of
> thinking about Wicket deeply enough to know the best approaches to
> things.
>
> It's why I came here with a question like what would be the better way
> of doing this. Having had fragments pointed out to me (I knew more
> about panels, I think... at least to the extent of using them to wrap
> other components), and possibly thinking in terms of repeaters even
> though it's only going to be 2 or 3 things, I'll try to find some time
> and go back over some tutorials.
>
> On 8/29/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > 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]
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
