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
