Re: Two small questions

[Sebastiaan van Erk]

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.

Regards,
Sebastiaan

Yes, and it makes the component have that nice wicketty "lightweight" feel... :-))

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

smime.p7s
Description: S/MIME Cryptographic Signature