hi sebastiaan,

what you could do instead of having the beforeDisabledLink and
afterDisabledLink properties as members of the class,
let the methods get(Before|After)DisabledLink return "<li>" and "</li>".
in case the user wants to provide different before/after tags, they just
override the methods and let them return something else.
to quote eelco (see WICKET-661): "It's a bit cheaper on memory like that."

you might also want to extend AbstractBehavior instead of implementing
IBehavior from scratch. saves a few "// do nothing" methods.

any objections to that?

cheers,
  gerolf

On 9/13/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I decided to wrote a behavior to do what I want. Just in case anybody is
> interested, I will attach it to this email. You can use it like so:
>
>         ExternalLink externalLink = new ExternalLink("externalLink",
> "http://www.google.com";);
>         externalLink.add(new DisableLinkBehavior());
>         externalLink.setEnabled(enabled);
>         add(externalLink);
>
> The output is exactly the same as with Link. You can also specify
> "beforeDisabledLink" and "afterDisabledLink" strings in the constructor
> of DisableLinkBehavior if you don't like the default <i> </i>.
>
> Regards,
> Sebastiaan
>
>
>
> Sebastiaan van Erk wrote:
> > Hi,
> >
> > It indeed looks more like an omission than a bug. I'll make a feature
> > request out of it. :-)
> >
> > Regards,
> > Sebastiaan
> >
> > Jonathan Locke wrote:
> >>
> >> yeah, more like an omission, but this is definitely a problem so far as
> i
> >> recall.
> >>
> >>
> >> Kent Tong wrote:
> >>>
> >>>
> >>> Sebastiaan van Erk wrote:
> >>>> Ok, to answer my own question, it seems that ExternalLink does not
> >>>> have the ability to be disabled like Link.
> >>>>
> >>> Looks like a bug to me. I'd suggest that you submit a JIRA issue at
> >>> http://issues.apache.org/jira/browse/WICKET
> >>>
> >>
>
>

Reply via email to