On 9/13/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Gerolf Seitz wrote:
> > 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?
>
> No problem, you guys are welcome. :-)
> I will attach it to issue.
>
> > as you said, you'd probably subclass the behavior anyway to provide an
> > application wide implementation.
>
> Yes, and the more I think about it, the more I like it the way you
> suggested...
>
> > it's just that it seems to be the wicketier way with overriding the
> methods.
>
> Yes, and it makes the component have that nice wicketty "lightweight"
> feel... :-))
cool, alright then ;)
gerolf
Regards,
> Sebastiaan
>
> > 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
> >>>>>>>
> >>
> >
>
>
