DWR Best Practices and Limitations
DWR Best Practices and Limitations
Best Practices
- Use create "null" to expose server session object, for example shoppingCart.
- Only expose the required properties of the model by using "include".
- Customize the bean converter - the default DWR bean converter uses new operation on inbound conversion (from js object to java object). This does not work when a constructor is not exposed.
- EP bean converters
- EpBeanConverter - Used to handle all persisted beans.
- Utility converter - these are used for some special needs, i.e., as a workaround for not being able to use objects as the map key in JavaScript.
- EpCurrencyConverter (converts java.util.Currency object to/from java.lang.String)
- MoneyFormatter (converts Locale and Money types to/from a java MoneyFormatter)
Limitations
- JavaScript does NOT support method overloading, so it is impossible to expose two Java methods with the same name but different signatures
- You can not expose methods in non-singleton domain objects. If you want to expose business logic inside a domain object, you will need to create a wrapper method in the service layer.
- Only maps with String or other primitive-typed keys can be used in JavaScript.
Note: Tip
Using complex types as hash keys presents a problem when trying to expose the map to the client side. In JavaScript, array keys must be literals. The following are identical:
var a={3:"hello"}; var a={"3":"hello"};
As a result, the java Map with a complex object as the key cannot be converted by DWR as it is. There are two workarounds:
- Always use Maps with String keys.
- Leave the map with the complex typed key, and customize the DWR Converter to take care of the difference.
Solution 1 is preferred. When using solution 2, there will be some performance overhead and different object representation on the client and server side.