Dr. Dobb's Journal - March 2008 - (Page 59)

the button is clicked, the method doFumble() gets called, which in this case, disables the button (to prevent the user from clicking twice), and then performs some business logic. In this example, there is an obvious drawback—the button is only disabled after at least a client-server roundtrip, but also after all the fumbling has been done! This can easily be avoided by using client-side event handling. 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 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 crossbrowser 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 Web applications developed with Wt typically enjoy greater efficiency and a smaller footprint than Java or Ruby solutions JavaScript again. Obviously, this kind of solution is not sufficient if the fumbling is not something that we expect the user to do repeatedly. 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. DDJ March 2008 l www.ddj.com l Dr. Dobb’s Journal 59 http://www.leadtools.com/ http://www.leadtools.com/ http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - March 2008

Dr. Dobb's Journal - March 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Social Networks and Software Development Conversations Detecting Bugs in Safety-Critical Code Change Code Without Fear Continuous Integration and Performance Testing Wt: A Web Toolkit Automating Release Notifications The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.