You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Joachim Schrod <js...@acm.org> on 2015/01/08 03:15:27 UTC
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: jschrod@acm.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: AJAX-Behavior that decides activation of a link
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Thu, Jan 8, 2015 at 10:45 PM, Joachim Schrod <js...@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 <js...@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: jschrod@acm.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Joachim Schrod, Roedermark, Germany
> Email: jschrod@acm.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: AJAX-Behavior that decides activation of a link
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
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
Posted by Joachim Schrod <js...@acm.org>.
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 <js...@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: jschrod@acm.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joachim Schrod, Roedermark, Germany
Email: jschrod@acm.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: AJAX-Behavior that decides activation of a link
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
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 <js...@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: jschrod@acm.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Regards - Ernesto Reinaldo Barreiro
Re: AJAX-Behavior that decides activation of a link
Posted by Joachim Schrod <js...@acm.org>.
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" <js...@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: jschrod@acm.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: AJAX-Behavior that decides activation of a link
Posted by Boris Goldowsky <bg...@cast.org>.
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" <js...@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: jschrod@acm.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org