April 19, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

A Field Guide to Java Direct Web Remoting (DWR), Page 2

  • May 3, 2007
  • By Vlad Kofman, Vlad Kofman
  • Send Email »
  • More Articles »

Testing DWR

The DWR Servlet is very robust. It can output dynamic JavaScript code, it can correctly route Ajax calls, and it can even be used to debug the DWR logic. The debugging and testing functionality is conceptually similar to some implementations of Web Services test clients provided by different application sever vendors, such as BEA or IBM.

Recall that the DWR Servlet was mapped under the dwr pattern in the web.xml file.

<url-pattern>/dwr/*</url-pattern>

Client JSPs (or HTML files) can request dynamic JavaScript from the server by referencing this name in the path.

Also, recall that in the dwr.xml file there is a definition to expose ItemManager class.

allow>
   <create creator="new" javascript="ItemManager">
   param name="class" value="model.ItemManager" />

To use this object and its methods on the client page, DWR exposes a corresponding JavaScript file generated dynamically, when the client requests a specially defined URL from the server (via the dwr pattern path). The Servlet will generate and output this file on the fly.

The general format for the dynamic address is:

/[WEBAPP-NAME]/[MAPPING-NAME]/interface/[CLASS-NAME].js'

In the <script> tag, this address is set as the src attribute's value. For example:

<script type='text/javascript'
src='/[WEBAPP-NAME]/dwr/interface/ItemManager.js'></script>

Including this in your page is perfectly valid and if you call this address directly, you will see the actual JavaScript code, even though this file does not exist on the server.

If you want to debug/test the DWR calls, the DWR Servlet needs to be in debug mode in the web.xml file. To enable debug, set the parameter for debug to true. Note that this is probably not desirable in production because it shows all available methods of the object to the client.

<init-param>
   <param-name>debug</param-name>
   <param-value>true</param-value>
</init-param>

To see the test client point your browser to

/[WEBAPP-NAME]/[MAPPING-NAME]/

This will show all exposed objects, and if you click on the object name, you will see available methods—both exposed and not exposed by the DWR.

Only exposed methods are callable directly on the test page.

Notice that the methods defined in the dwr.xml are active and some methods even take parameters.

Considering that this is all auto-generated for you by the DWR Servlet, using this technology becomes trivial. The test client even pre-generates the JavaScript includes needed to use the exposed objects.

Conclusion

In this article, you looked at Direct Web Remoting (DWR)—a unique way to use AJAX and call Java on the server from the client side. This technology is conceptually similar to the Web Services implementations, but designed only to work with Java and JavaScript. Currently, DWR is popular and continues to gain popularity. The technology is stable, albeit with some limitations, has good documentation, and is straightforward to set up and use. If you are looking for a way to expose existing Java code to clients, and do not want to deal with complexities and incompatibilities of Web Services toolkits, you should definitely take a closer look at DWR.

Download Source

Download the source code for the article here. The author would like to acknowledge and thank James Harmon for his contribution of the source code.

Reference

DWR: http://getahead.org/

About the Author

Vlad Kofman is working on enterprise-scale projects for the major Wall Street firms. He has also worked on the defense contracts for the U.S. government. His main interests are object-oriented programming methodologies, UI, and design patterns.





Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel