Hi, On Thu, Jan 8, 2015 at 10:45 PM, Joachim Schrod <jsch...@acm.org> wrote:
> 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. > Ajax is asynchronous. event.preventDefault() is processed long before the request is processed by the server. Even longer that the processing of the response at the client. You can use synchronous Ajax call to accomplish this but this is not recommended. It will freeze the browser tab until the response is processed. > > 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 <jsch...@acm.org> 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: jsch...@acm.org > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > > > > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Joachim Schrod, Roedermark, Germany > Email: jsch...@acm.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
