DWR has a new release that should be pretty stable, with a final release coming soon.

Features

• The biggy is Guice support. If it wasn’t for the fact that we could add this in without touching the core of DWR, I’d say this was too big a change at this point in the release cycle, however Tim Peierls (who you might know from this project) has done a stack of work to make DWR and Guice play really well together. You can read more about the background on Tim’s blog.
• Security: The Fortify review highlighted some areas where DWR was lacking. You can read more about what DWR now does to protect you in the DWR security documentation.
• Reverse Ajax: There have been some cases where reverse ajax has not been as stable as it should be. I hope that most of those are now behind us.

The reverse Ajax features are really quite something. If you haven’t checked them out yet, do so.

There are 2 ways to get started with DWR, the easy way is to download the WAR file and have a look around, however this does not help you see how easily DWR integrates with your current web application, so the following 3 simple steps are recommended:

1. Install the DWR JAR file

Download the dwr.jar file. Place it in the WEB-INF/lib directory of your webapp. You’ll probably have a set of jar files in there already.

2. Edit the config files

The following lines need to be added to WEB-INF/web.xml. The <servlet> section needs to go with the other <servlet> sections, and likewise with the <servlet-mapping> section.

<servlet>
  <servlet-name>dwr-invoker</servlet-name>
  <display-name>DWR Servlet</display-name>
  <servlet-class>uk.ltd.getahead.dwr.DWRServlet</servlet-class>
  <init-param>
     <param-name>debug</param-name>
     <param-value>true</param-value>
  </init-param>
</servlet>

<servlet-mapping>
  <servlet-name>dwr-invoker</servlet-name>
  <url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

Then create a dwr.xml file that lives in WEB-INF alongside web.xml. A simple way to start is with something like this:

<!DOCTYPE dwr PUBLIC
    "-//GetAhead Limited//DTD Direct Web Remoting 1.0//EN"
    "http://www.getahead.ltd.uk/dwr/dwr10.dtd">

<dwr>
  <allow>
    <create creator="new" javascript="JDate">
      <param name="class" value="java.util.Date"/>
    </create>
    <create creator="new" javascript="Demo">
      <param name="class" value="your.java.Bean"/>
    </create>
  </allow>
</dwr>

The DWR config file defines what classes DWR can create and remote for use by Javascript. In the example above we are defining 2 classes that are remoted and giving the classes names in Javascript.

The new creator that we used above uses the public no-args constructor that all JavaBeans must have. It is also worth remembering that DWR has a few restrictions:

• Avoid reserved JavaScript words; Methods named after reserved words are automatically excluded. Most JavaScript reserved words are also Java reserved words, so you won’t be having a method called “try()” anyway. However the most common gotcha is “delete()”, which has special meaning from JavaScript but not Java.
• Overloaded methods can be involved in a bit of a lottery as to which gets called, so avoid overloaded methods.

3. Go to the following URL

http://localhost:8080/[YOUR-WEBAPP]/dwr/You should see a page showing you the classes that you’ve selected in step 2. Having followed a link you should see an index of all the methods all ready for calling. These pages are dynamically generated examples of what you can do using DWR.

Kick the tyres and have a look around.

How to make use of this from your web application

There are a number of examples in the sidebar that demonstrate how to dynamically alter the text in web pages, update lists, manipulate forms and do live table editing. Each has a description of how it works.

Another way to get started is to look at the source from the pages that you just viewed:

• Go to http://localhost:8080/[YOUR-WEBAPP]/dwr/ and click on you class
• View source and find the line that executes the method that you are interested in.
• Paste the text into an HTML or JSP page in your web-app.
• Include links to the javascript files that make the magic happen:

<script src='/[YOUR-WEBAPP]/dwr/interface/[YOUR-SCRIPT].js'></script>
<script src='/[YOUR-WEBAPP]/dwr/engine.js'></script>

You can omit the /[YOUR-WEBAPP]/ section and use relative paths in your web pages if you wish.

For more information about how to write Javascript that interacts with DWR see the scripting introduction.

What if it doesn’t work?

We have a log of common problems and their fixes. This is the first place to look.

If you are still having problems please join the mailing list and ask there.

DWR version 2.0 milestone 1 is released.

This is probably the biggest release we’ve ever done in terms of new features.

Reverse Ajax

The biggest new feature is what we call Reverse Ajax. DWR 1.x allowed you to asynchronously call Java code from Javascript. DWR 2.0 builds on this to allow you to asynchronously call Javascript code from Java. Reverse Ajax makes writing interactive applications much easier. It can use polling or Comet (long-lived HTTP) queries.

Our ‘chat’ example contains Java code like this:

// Get the current page

WebContext wctx = WebContextFactory.get();

String currentPage = wctx.getCurrentPage();

 

// ’messages’ is a List of recent messages for a browser to display

// Java objects converted to Javascript have a declaration and a declared variable name.

OutboundVariable ov = wctx.toJavascript(messages);

 

// Loop over all the users on the current page

for (ScriptSession otherSession : wctx.getScriptSessionsByPage(currentPage)) {

    otherSession.addScript(ov.getInitCode() );

    otherSession.addScript(“receiveMessages(” + ov.getAssignCode() + “);” );

    // receiveMessages is a Javascript function that displays the current list of messages

}

In essence we are looping over all the users on the current page and sending them some Javascript to update their display. The Javascript is even simpler. You just turn polling on:

DWREngine.setPolling(true);

Chat example (included in the war download) includes the Javascript source to receiveMessages() which is a 4-liner that uses DWRUtil to put the messages on the screen.

Other uses for this technology include progress bars, online games, stock tickers and any system where server state changes and we need to push updates to a browser or browsers.

Cross Domain Ajax: <script> tag manipulation

Should you need to access servers in a different domain we’ve enabled a new remoting scheme. From DWR 2.0 you can use manipulation of <script> tags in addition to XMLHttpRequest or iframes. To use is you just need to do the following:

DWREngine.setMethod(DWREngine.ScriptTag);

The <signatures> Element

DWR 1.x sometimes needs a <signatures> element to help it get the type conversion right. If you are using DWR 2.0 with JDK5 generic types then you probably don’t need <signatures> any more. DWR will automagically get the right type conversion.

DWRUtil Updates

We’ve updated DWRUtils. There is a new DWRUtil.cloneNode(elementId) method that enables you to use HTML fragments as templates that are repeated. For example:

// Loop over all the beans

for (var i = 0; i < beanArray.length; i++) {

  // Fill in the blanks in the template. You will have several lines like this.

  DWRUtil.setValue(“someid”, beanArray[i].property);

  // Clone the node so we don’t overwrite it next time

  DWRUtil.cloneNode(“template”);

}

 

// Finally hide the template

$(“template”).style.display = “none”;

We’re also trying an experimental update to getValues to make it work more like a form. A Checkbox will return its value if checked and false if not. This might break backwards compatibility, it is slight non-obvious depending on your perspective so we need feedback on this one.

New Attribute Scope - Script

There is a new scope. Servlet/JSP developers are familiar with setting attributes at a request, page, session or application level. DWR 2.0 allows you to use “script” scope. With script scope you can persist variables for long-lived pages like single-page Ajax applications. Script scope is a bit like session scope in its longevity, however it does not require cookies. Script scope attributes are available to any Ajax operations within a single page. It is available to creators dwr.xml:

<create creator=“new” javascript=“Test” scope=“script”>

  <param name=“class” value=“com.example.Test”/>

</create>

Script scope is also available programatically:

WebContextFactory.get().getScriptSession().setAttribute(“key”, value);

Examples

Starting with DWR 2.0m1 the downloadable war file is quite a bit bigger than before because we are including some examples. We are working on simple Struts and Spring integration demos.

Refactoring

Refactoring is often a feature in the eyes of developers because the code feels cleaner, but it can just cause backwards compatibility issues for users. We’ve done some refactoring for DWR 2.0, but here is what users get out of it: We now use the org.directwebremoting.* package rather than the more obscure uk.ltd.getahead.dwr.*, but we’ve left stubs behind for backwards compatibility. Please shout if we’ve missed anything out. We’ve also tried to make DWR more embeddable, and it should now be possible to create alternative wire protocols like SOAP or JSON-RPC if desired.

Call Meta-data

You can now pass request attributes from DWR using call meta-data like this:

Remote.getData(42, {

  callback:function(str) { alert(str); },

  customKey:“Fred”,

});

 

The extra meta-data will then be available to Java in the HttpServletRequest. The following code will return the string “Fred”:

WebContextFactory.get().getHttpServletRequest().getAttribute(“customKey”);

Other Stuff

I very much doubt that anyone will notice, but we’ve removed deprecated.js. It’s been deprecated since around DWR version 0.9.

Security and Stability

We take security very seriously. DWR 1.x has proved to be very secure so far, but that does not mean we rest on our laurels. DWR 2.0 introduces a lot of new code. Reverse ajax and script based session management are places where we could easily slip up.

In addition in milestone 1, Reverse Ajax will create a much heavier load on your webserver than older stable releases. We’ve got 2 answers - the design allows server load-monitoring and dynamic back-off. More excitingly we’re working with Mortbay to allow DWR to use Jetty6 continuations if available to allow long lived HTTP requests without risking resource starvation.

So please do not use DWR 2.0 in a production system until we’ve had more testing and inspections.

Future Releases

This is just the first in an exciting set of milestones that we will be pushing out over the next few weeks. We’ve got more stuff coming!

Download

You can download DWR 2.0 M1 from the usual download page.