Package eu.webtoolkit.jwt

Class JSlot

java.lang.Object
eu.webtoolkit.jwt.JSlot
public class JSlot extends Object
A slot that is only implemented in client side JavaScript code.

This class provides a hook for adding your own JavaScript to respond to events.

Carefully consider the use of this. Not only is writing cross-browser JavaScript hard and tedious, but one must also be aware of possible security problems (see further), and of course, the event handling will not be available when JavaScript is disabled or not present at all.

For some purposes, stateless slot implementations are not sufficient, since they do not allow state inspection. At the same time, the non-availability in case of disabled JavaScript may also be fine for some non-essential functionality (see for example the WSuggestionPopup widget), or when you simply do not care. For these situations a JSlot can be used to add client-side event handling.

The JavaScript code may be set (or changed) using the setJavaScript() method which takes a string that implements a JavaScript function with the following signature: 


 function(sender, event) {
 // handle the event, and sender is a reference to the DOM element
 // which captured the event (and holds the signal). Therefore it
 // equivalent to the sender for a normal JWt slot.

 // You can prevent the default action using:
 var fixed = jQuery.event.fix(event);
 fixed.preventDefault();
 fixed.stopPropagation();
 }

In the JavaScript code, you may use WWidget.getJsRef() to obtain the DOM element corresponding to any WWidget, or WObject.getId() to obtain the DOM id. In addition you may trigger server-side events using the JavaScript WtSignalEmit function (see JSignal documentation).

A JSlot can take up to six extra arguments. This is so that a JSignal can pass its arguments directly on to a JSlot, without communicating with the server.

That's how far we can help you. For the rest you are left to yourself, buggy browsers and quirky JavaScript (http://www.quirksmode.org/ was a reliable companion to me) – good luck.

Note that the slot object needs to live as long as you want the JavaScript to be executed by connected signals: when the slot is destroyed, the connection is destroyed just as with other signal/slot connections where the target object is deleted. This means that it is (almost?) always a bad idea to declare a JSlot on the stack.