Re: AJAX-Behavior that decides activation of a link
Hi, On Thu, Jan 8, 2015 at 10:45 PM, Joachim Schrod 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 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 > >
Re: AJAX-Behavior that decides activation of a link
Hi,
Apologies, I might have not understood your requirements correctly.
Comments inline.
> 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.
>
You can do want at server side to trigger something or not at client side.
E.g. you can create:
1- A client side map var bottonStates={} ---> ["buttonID"]=true/false;
2- On your event your event you get your ART and
art.appendJavaString("bottonStates['"+getMarkupId()+"']="+true/false.
3- Create a type of link that checks this map before firing.
The same trick can be used for other types of info you want to pass to
client side.
No need for hidden fields.
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.
>
See comment above.
Just roll your own version of a link. E.g.
1- A JS prototype for your links.
2- These links check state map (at client side) to execute or not... and
also if there is some message to be displayed.
> 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.
>
What I meant is that for any pertinent ART you can generate a new type of
event that tells all your links "Hey guys, do you have a different sate to
report? and give the opportunity to them to do so."
> Sorry, but I don't get it. Maybe your Wicket usage is way above my
> head?
>
I do not think so... :-(
> 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?
>
Yep... Or let it fail gracefully... Server side instead of performing the
desired action just answers back. Hey guy, that's not allowed right now.
> 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.)
>
Then you might want them to fail gracefully... E.g using something like.
http://www.erichynds.com/examples/jquery-notify/
By the way, I have a private implementation of this (wicket 6.x
compatible), that I might share with the community. E.g. via wicket-stuff.
--
Regards - Ernesto Reinaldo Barreiro
Re: AJAX-Behavior that decides activation of a link
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 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
Re: AJAX-Behavior that decides activation of a link
On 01/08/15 15:50, Boris Goldowsky wrote: > If I¹m understanding you correctly, wouldn¹t it be sufficient to code this > as > a simple AjaxLink, which responds with a regular AJAX > update when the link is disabled, or uses setResponsePage when it¹s > enabled? The link in question delivers a PDF document, and has target="_blank" to do that in a new tab. In fact, there are several of these links, and only some of that have the controlling behavior. Thus prevention of the default action is essential, to prevent opening a new tab. I also had a solution that used window.open() in JS -- but that code wasn't any prettier. I think what I'm looking for is a way to add some client data to an ART target that I can access client-side, e.g., in an AJAX call listener. Thanks for your comments, Joachim > On 1/7/15, 9:15 PM, "Joachim Schrod" 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
Re: AJAX-Behavior that decides activation of a link
If I¹m understanding you correctly, wouldn¹t it be sufficient to code this as a simple AjaxLink, which responds with a regular AJAX update when the link is disabled, or uses setResponsePage when it¹s enabled? Boris On 1/7/15, 9:15 PM, "Joachim Schrod" 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 > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AJAX-Behavior that decides activation of a link
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 On Thu, Jan 8, 2015 at 2:15 AM, Joachim Schrod 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 > > -- Regards - Ernesto Reinaldo Barreiro
AJAX-Behavior that decides activation of a link
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
