DWR 3.0 conversion features

So DWR 3 is slated for late September around the Ajax Experience conference (tentative dates, of course) and it's loaded with new features. I've already talked about some of them (like Spring) but right now there's a lot of work being done with converters so I'd like to share some of it a little.

Before, of course, a little explanation to inform clueless people. A converter in DWR is an object that transforms Java to Javascript and vice versa. This is usually transparent to the user as DWR out-of-the-box includes converters for primitive types, arrays, collections, beans and more. Of course, for security reasons not all of these converters are enabled by default and some require a specific declaration (like bean or exception). The conversion procedure is composed of two stages, the inbound conversion that transforms method arguments from JS (using a internal protocol named DWRP) and the outbound conversion of the response (or the method return type).

Advanced users know the use of class mappings as well. These serve two purposes, first they allow a Java to JS object correspondence and (internally) they also add runtime information to each call.

We can look now into the new features 3.0 offers. But first remember (a little disclaimer) that they are currently under heavy work so many are not yet ready but in the working copies of the developers boxes. No more delays, here they are:

• New converters
  An obvious one, more out-of-the-box converters mean less work for each developer. The interest relies in the functionality though. These ones allow file and image transfers using AJAX calls. That is, uploads and downloads using asynchronous calls and progress listeners.
• Dot syntax support
  To date JS objects mapped just the name of the Java class but omitted the package. This has been enhanced to support the fully qualified name. An example that shows hierarchies as well:
  
  
  var baz = new foo.bar.BazImpl
  ...
  if (baz instanceof foo.bar.Baz) {..}
  
  
• Classpath scanning
  Before now, each converter required its own declaration. From now on the match clause accepts wildcards to define converters in batch during boot time. They syntax is pretty clear match="foo.*" will locate any class under the foo package while match="foo.bar.**" will, in addition, recurse subfolders.
• Javascript wildcard expansion
  In the same manner as the previous point the javascript attribute of a converter will allow wildcards (both * and **) that will be expanded to the corresponding class name. Thus, * will map to the matched class simple name while ** will be mapped to the fully qualified named (thanks to the dot syntax support). Expect definitions like:
  
  
  <converter type="bean" match="model.**" javascript="foo.bar.*" />
  
  to remote all the classes under the model package (including subpackages) under the JS identifier of foo.bar.<SimpleClassName>.
• Method overloading
  Till today, DWR just politely asked the developer not to overload methods (on the server side). New enhancements in the inbound conversion process allows better identification of the target method and thus overloading.
• Var args support
  3.0 will offer support for Java varargs using JS arrays as the last parameter of a method.
• Interfaces as method parameters
  It will be possible to declare method signatures that include interfaces (or abstract classes) as long as there is at least one converter declared that implements the contract and runtime type information is delivered with the request (class mappings are mandatory). This is an example of why the library prefers DWRP over JSON to transfer data.
• Separated class mappings
  Class mappings are currently defined in every interface file. This leads to duplication and overall worse performance. Next version maintains this behavior for compatibility reasons but adds the possibility to generate class mappings gropued in a external file (to be used with JAWR for example) or just one per file
• Improved serialization
  Next version will detect and avoid the serialization of JS properties that are not mapped in the Java counterpart.
• Constructor injection
  JS classes will be instantiated from a map in addition to the usual setter injection.

And there are some more (like property overriding in conversion) but they may not be ready for 3.0 and will have to wait until the following release.