Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink
	TABLE OF CONTENTS Wt: A Web Toolkit Library Overview Deployment Architecture Server-Side Event Handling Client-Side Event Handling

Client-Side Event Handling

While server-side event handling can in principle do any kind of event handling, there are limitations because of the latency involved with the client-server roundtrip. When JavaScript is available in the browser, this roundtrip would not be necessary provided that the event handling is specified in JavaScript code. Even ignoring the extra complexity of specifying part of the functionality in JavaScript, and the bad reputation of that language (and its implementations), there are more fundamental problems with specifying part of the functionality in JavaScript. First, an alternative must be provided when JavaScript is not available. Second, the server-side application state is no longer synchronized with the browser-side state. Furthermore, with custom JavaScript, Wt cannot guarantee robustness against XSS attacks and cross-browser compatibility.

Wt provides an attractive alternative, which is a dynamic C++-to-JavaScript translation mechanism for so-called stateless slots in Wt. A stateless slot is any slot that adheres to the contract to always have the same visual effect regardless of application state. For example, to unconditionally disable the button as soon as it is clicked, as it is in MyWidget::doFumble(), no application state or event details are required and therefore the stateless slot learning in Wt may be used to implement this event handling in client-side code.

Consider the code changes in Listing Two. The effect of this code is that the JavaScript code for the MyWidget::disableFumbleButton() slot is learned on the first invocation of the event, and cached in the browser. Thus, the first invocation will require a server roundtrip before rendering the visual update, but subsequent invocations will simply execute the JavaScript again. Obviously, this kind of solution is not sufficient if the fumbling is not something that we expect the user to do repeatedly.

class MyWidget : public WCompositeWidget
{
public:
  MyWidget(WContainerWidget *parent = 0)
    : WcompositeWidget(parent),
      ...
   {
      ...
      implementStateless(&MyWidget::disableFumbleButton);

      fumbleButton_ = new WPushButton("Fumble");
      fumbleButton_
        ->clicked.connect(SLOT(this, MyWidget::disableFumbleButton));
      fumbleButton_->clicked.connect(SLOT(this, MyWidget::doFumble));
      ...
   }
private:
   WpushButton *fumbleButton_;
   void disableFumbleButton()
   {
      fumbleButton_->disable();
   }
   void doFumble()
   {
      fumbleSome(...);
   }
};

With some extra effort, we may also eliminate the roundtrip for the visual update at the very first invocation. By letting the library invoke a stateless slot internally even before it is actually triggered by client-side code, the library may learn the visual changes that are implied by it. To undo the effect of this spontaneous internal invocation, an undo function must be provided.

Applied to the same example, you would change the call to:

implementStateless
  (&MyWidget::disableFumbleButton,
   &MyWidget::undoDisableFumbleButton);

and implement this undo method:

void undoDisableFumbleButton()
{
  fumbleButton_->enable();
}

The library provides stateless implementation for many of its built-in widget methods, such as WWidget::hide() and WWidget::show(), but incidentally also for WFormWidget::enable() and WFormWidget::disable(). Because it is convenient to connect these little methods directly to signals, the client-side optimization is automatically provided with the construct in Listing Three.

class MyWidget : public WCompositeWidget
{
public:
  MyWidget(WContainerWidget *parent = 0)
    : WcompositeWidget(parent),
      ...
   {
      ...
      fumbleButton_ = new WPushButton("Fumble");
      fumbleButton_
        ->clicked.connect(SLOT(fumbleButton_, WPushButton::disable));
      fumbleButton_->clicked.connect(SLOT(this, MyWidget::doFumble));
      ...
   }
private:
   WpushButton *fumbleButton_;
   void doFumble()
   {
      fumbleSome(...);
   }
};

Previous Page | 1 Wt: A Web Toolkit | 2 Library Overview | 3 Deployment Architecture | 4 Server-Side Event Handling | 5 Client-Side Event Handling

RELATED ARTICLES Logging In C++ : Part 2 SDK, .NET Controls Released for Communications Enabling Web Pages Welcome To the World of Cryptographic Voting recls 100% .NET Jetbrains Updates Ruby IDE		TOP 5 ARTICLES No Top Articles.