Hi Sven & Martin, Giving your comments, I did a second proposal: https://github.com/sebfz1/wicket/commit/7337f1db77877aaeeaadb4ac9f1173ffac3defe3
What has changed: - AbstractLink#canCallListenerInterface has been overridden - AbstractSubmitLink#isLinkEnabled is marked as final I successfully tested with Link, AjaxLink, AjaxSubmitLink and BookmarkablePageLink. Quickstart is here: https://github.com/sebfz1/wicket-quickstart-islinkenabled Thanks & best regards, Sebastien. On Mon, Jan 19, 2015 at 7:32 PM, Sebastien <[email protected]> wrote: > Hi Sven & Martin, > > I've did an attempt to restore #isLinkEnabled based on Martin's > suggestion. You can see the proposal here. > > https://github.com/sebfz1/wicket/commit/1af4bbbd6b11e151d4143cefa2be8ad6c441bd65 > > I should say I did not tested it yet, but if you agree on the principle I > will try to add some tests... > > Thanks & best regards, > Sebastien. > > > On Mon, Jan 19, 2015 at 3:46 PM, Sebastien <[email protected]> wrote: > >> Hi Sven, >> >> > setEnabled(false) will make the component disabled, whatever >> #isEnabledInHierarchy() may return. >> >> Absolutely, sorry for the misunderstanding. I was meaning >> #setEnabled(true) - which does not have priority over >> #isEnabledInHierarchy() >> >> > Overriding #isLinkEnabled() wasn't a sufficient solution (I think you'd >> have to override #canCallListenerInterface() too) and didn't work for >> AjaxLinks either. >> >> Not sure I will like this solution... :s >> But if you are going to not restore #isLinkEnabled(), be prepared to some >> disappointed people when they will migrate to 7! ;) >> >> Thanks & best regards, >> Sebastien. >> >> >> On Mon, Jan 19, 2015 at 3:25 PM, Sven Meier <[email protected]> wrote: >> >>> 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. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>> >> >
