On 01/08/15 08:15, Ernesto Reinaldo Barreiro wrote: > Hi, > > I would use server side activation. Implemented as in > > 1- You can create your own events, e.g. [1]. One that is a wrapper of AJAX > request target (e.g. AtivateLinksEvent). > 2- Your links will listen for AtivateLinksEvents and decide if they should > be enabled or not (and add themselves to ART on AtivateLinksEvent). > > > References: > > 1- > https://github.com/reiern70/antilia-bits/blob/master/bgprocess/src/main/java/com/antilia/panel/TaskLaunchedEvent.java
I don't grasp your intent completely. I get that I can define my own event classes server-side. I don't get how that helps me client side. My problem is: How do I communicate to client-side within an event handler that attrs.event.preventDefault() shall be called for exactly that event handler or not. Wicket provides a static pre-made decision via AjaxRequestAttributes; I want a dynamic one. I looked at the code you cited, and the enable/disable decision is done server-side, right? But how does introduction of a new event type help with my problem client-side? Adding the links to ART on some event won't change anything, as this won't influence the _original DOM event_ (attrs.event) that controls if default action is taken or not. I also can't see how that new Wicket event type would give me access to that DOM event I want to influence. Sorry, but I don't get it. Maybe your Wicket usage is way above my head? Or, do you mean that the server shall decide, according to previous user actions, that the link is enabled from now on and then shall change the link in an ART? Also disabling it back, as needed? That's hard to do, some parameter for the enable/disable decision are external availability of resources that are checked at the moment of link activation. (The actual link almost always works. The behavior shall implement proper error checking and reporting in case of unavailable resources or other errors that are beyond the user's realm.) Thanks for your answer, and for digging out that link, Joachim > On Thu, Jan 8, 2015 at 2:15 AM, Joachim Schrod <[email protected]> wrote: > >> Hi, >> >> I have a class of links where some of them sometimes shall not >> trigger. The decision is made server-side according to current state. >> >> At first sight, the realization seems to be not that straight forward: >> -- I add an AJAX behavior to these link that allows default action >> and computes if the link action shall be prevented. >> -- The AJAX behavior has an AJAX call listener (complete handler) >> that may call attrs.event.preventDefault() if the link shall >> not be triggered. >> -- The decision if the link shall not be triggered is >> communicated by the AJAX request to the complete handler via >> an HiddenField that is updated in the AJAX request. Delivery >> of the decision via JSON is difficult, as we also want to >> update other DOM elements with the response (feedback why the >> link was not triggered). >> >> Do I miss something? Is there a completely different approach that >> I could take? >> >> Or: Is there a better way to communicate the decision if the link >> shall be triggered to the call listener? Introducing a hidden field >> for that purpose seems to be awkward, for me. >> >> I would be thankful for any comments or recommendations. >> >> Joachim >> >> -- >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Joachim Schrod, Roedermark, Germany >> Email: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod, Roedermark, Germany Email: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
