On 8/30/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.
Irritated? You obviously lack basic Wicket knowledge even though you claim
to be using it for months ("Now, after months of using Wicket..."). But
happily, you don't let that fact hinder you from bitching about Wicket. This
certainly isn't the right attitude if you come here for help.
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...
Doesn't have to be. You should use panels or fragments for things like
this. There is no reason for unused component placeholders.
After months of using Wicket, this might be the right time to learn about
panels and fragments...
-Matej
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]
>
>
