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. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >> >
