Hi Sebastien,
>Still from my understanding #isEnabledInHierarchy takes priority
>over #setEnabled(false). So #setEnabled(false) won't have any
>effect if the parent (a Form for instance) is disabled
setEnabled(false) will make the component disabled, whatever
#isEnabledInHierarchy() may return.
> there is probably numerous use-cases where we/users still want a link
>to be enabled even if the parent container is disabled.
Agreed. Whoever needs this, should open a feature request.
Overriding #isLinkEnabled() wasn't a sufficient solution (I think you'd
have to override #canCallListenerInterface() too) and didn't work for
AjaxLinks either.
Have fun
Sven
On 19.01.2015 14:25, Sebastien wrote:
Hi Sven,
Actually I did not tried with wicket-6. I said it "would" answer the
use-case because this was my understanding.
you can override #isLinkEnabled(): But returning false does not make
sense IMHO, you an easily use #setEnabled(false) for that.
Still from my understanding #isEnabledInHierarchy takes priority over
#setEnabled(false). So #setEnabled(false) won't have any effect if the
parent (a Form for instance) is disabled, AFAIS
So I don't see a need for #isLinkEnabled() anymore.
I am figuring out this comment refer to the previous one. But just to
clarify (in case you were challenging the usefulness of #isLinkEnabled
itself):
From the user point of view (at least mine), it make sense wishing all
*form*-components to be disabled if the parent form is disabled. But, as a
link is not considered as a form component, there is probably numerous
use-cases where we/users still want a link to be enabled even if the parent
container (the Form here) is disabled.
My 2 cents...
Thanks & best regards,
Sebastien.
On Mon, Jan 19, 2015 at 1:05 PM, Martin Grigorov <[email protected]>
wrote:
I think the broader use case is to have disabled parent and enable just the
link inside it.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Jan 19, 2015 at 12:32 PM, Sven Meier <[email protected]> wrote:
Hi,
Sebastien wrote:
I am in a use case where my container is disabled, but still I would
like
my child link is enabled. Even #isLinkEnabled was just an helper to
isEnabledInHierarchy, it used to have the advantage to not being final,
so I could override it and this would answer my usecase...
I've rechecked the code in Wicket 6 and I don't see how that usecase was
supported.
Since commit f056e88453947c1377237db80adb5438ca00c693 you can override
#isLinkEnabled():
But returning false does not make sense IMHO, you an easily use
#setEnabled(false) for that.
Returning true, Ajax links will still *not* render their event handlers
and #canCallListenerInterface() will block any request anyway (event for
non-ajax links).
So I don't see a need for #isLinkEnabled() anymore.
Regards
Sven
On 19.01.2015 10:57, Martin Grigorov wrote:
What is the problem you see ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Jan 19, 2015 at 11:51 AM, Sven Meier <[email protected]> wrote:
Hi,
the opposite is more useful:
How to enable an AjaxLink, even if it's not enabled in the hierarchy?
Sven
On 19.01.2015 10:48, Martin Grigorov wrote:
Hi,
There are many people using #isLinkEnabled(). At least there were many
questions about it in the mailing lists.
I think we should override #renderHead()
at org.apache.wicket.ajax.markup.html.AjaxLink#newAjaxEventBehavior
and
don't call super if the link is disabled.
Same for AjaxFallbackLink.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Jan 19, 2015 at 11:35 AM, Sven Meier <[email protected]> wrote:
Hi again,
I've noticed that AbstractLink#isLinkEnabled() is broken for Ajax
links
since Wicket 6.x:
Yes, you can override #isLinkEnabled() to override
#isEnabledInHierarchy()
with true. But this does not have any effect on AjaxEventBehavior, it
just
doesn't register its event handler anyway.
I'm not sure we should reintroduce this broken method in 7.
Regards
Sven
On 15.01.2015 16:20, Sven Meier wrote:
Hi Sebastien,
seems I removed that method in back-and-forth of WICKET-4904.
I'll restore this functionality asap.
Regards
Sven
On 15.01.2015 15:08, Sebastien wrote:
Hi devs,
First of all, I would like to wish you an happy coding year! :)
I see there is some changes in AbstractLink between 6 & 7, and I am
wondering why #isLinkEnabled has been removed from there.
I am in a use case where my container is disabled, but still I
would
like
my child link is enabled. Even #isLinkEnabled was just an helper to
isEnabledInHierarchy, it used to have the advantage to not being
final,
so
I could override it and this would answer my usecase...
Would you agree to restore it?
Thanks a lot in advance,
Sebastien.
