sebastiaan,
sorry for not saying that in my first post: thank you for your contribution.
could you also attach this file to the issue WICKET-949?
as you said, you'd probably subclass the behavior anyway to provide an
application wide implementation.
it's just that it seems to be the wicketier way with overriding the methods.
anyway, again thanks...
gerolf
On 9/13/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Thanks for you constructive comments. Silly of me to not see the
> AbstractBehavior class, though I'm new to Wicket so I'm not too familiar
> with the API yet. :-) Thanks for the tip.
>
> As for returning the string constants in the
> get(Before|After)DisabledLink, I'm wondering if memory is that big an
> issue? AbstractLink also has these member fields. Futhermore, a one liner:
>
> externalLink.add(new DisableLinkBehavior("<b>", "</b>"));
>
> suddenly becomes much more verbose:
>
> externalLink.add(new DisableLinkBehavior() {
> @Override
> public String getBeforeLinkDisabled() {
> return "<b>";
> }
> @Override
> public String getAfterLinkDisabled() {
> return "</b>";
> }
> }
>
> And it only saves 4 bytes of memory in the latter case because it
> contains a hidden (unnecessary) reference to the outer class due to the
> fact it isn't a static inner class.
>
> Of course the obvious solution is to just create a subclass of
> DisableLinkBehavior with the (before|afterLinkDisable) fields and call
> it something like CustomLinkDisableBehavior or some such (especially
> since you would probably would use such a customization over an entire
> site). I'm still split on the issue though. :-)
>
> Anyway, I decided for now to take your approach.
>
> Here's the new class.
>
> Regards, and thanks again for the comments!
> Sebastiaan
>
> Gerolf Seitz wrote:
> > 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
> >>>>>
> >>
> >
>
>
