Wt::JSlot Class Reference

Wt::JSlot Class Reference
Signal/slot system
A slot that is only implemented in client side JavaScript code. More...
【JSlotはスロットであり、クライアントJavaScriptコードのみで実現される】#include <Wt/WJavaScript>
List of all members.
Public Member Functions
 
JSlot (WWidget *parent=0)
 
Constructs a JavaScript-only slot within the parent scope. 
 
JSlot (const std::string &javaScript, WWidget *parent=0)
 
Constructs a JavaScript-only and sets the JavaScript code. 
 
~JSlot ()
 
Destructor. 
void 
setJavaScript (const std::string &javaScript)
 
Sets or modify the JavaScript code associated with the slot. 【本スロットに関連付けられたJavaScriptコードの設定または変更】
void 
exec (const std::string &object="null", const std::string &event="null")
 
Executes the JavaScript code. 【setJavaScript()で設定したJavaScriptコードを実行する】
std::string 
execJs (const std::string &object="null", const std::string &event="null")
 
Returns a JavaScript statement that executes the slot. 
Detailed Description
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.
【Jslotはhookメカニズムを提供し、開発者がカスタムJavaScriptコードを追加してイベントに反応させることを許可します.】
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 ofcourse, the event handling will not be available when JavaScript is disabled or not present at all.
If you wish to add client side event handling, with automatic fall-back to server-side event handling and without writing JavaScript code with the associated risks and problems, consider using stateless slot implementations instead (see WObject::implementStateless())
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 %Wt slot.
   // You can prevent the default action using:
     ${WT_CLASS}.cancelEvent(event);
   // (where ${WT_CLASS} should be the value of the WT_CLASS define
}

In the JavaScript code, you may use WWidget::jsRef() to obtain the DOM element corresponding to any WWidget, or WWidget::id() to obtain the DOM id. In addition you may trigger server-side events using the JavaScript WtSignalEmit function (see JSignal documentation). 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.