The new DirectJNgine 2.2 version beta 1 is out.
DJN 2.2 provides the following new features:
Automatic conversion to a single element array when calling Java functions that expect an array but receive a single value.
This one helps get around the annoying behaviour ExtJs exhibits in some cases, as it can call a Java function with a single value or an array of values. Java, being type safe, can’t handle that.
MyAction.myFunction( 'hi', function(... MyAction.myFunction( ['hi','bye'], function(...
against the following java code,
public void myFunction( String values );
because DJN will turn the ‘hi’ sent by ExtJs for the first call into a single item array that will be acceptable to the Java function.
Please, note that this auto-conversion to arrays works only for the parameters themselves, not for values nested in the received data.
I feel that would be giving too much undue ‘flexibility’ to the client side: this auto-conversion trick is more of a workaround for ExtJs ‘liberal’ behaviour.
Added default Date serialiation, as explained here.
The default way dates are serialized by Gson is not very useful or easy to handle, and I decided to provide a custom default implementation that is easier to work with.
Just remember to check this link to make sure you understand how to handle it, and don’t forget to add the required code in the ExtJs side
Enhancements to unexpected server exception handling
This one is just experimental, so it might not get into 2.2 final. It will all depend on the feedback I get.
From my proposal draft…
Right now, when there is an unexpected exception at the server, DJN provides a
message, as per the Ext Direct specification.
While this message provides both the exception type (without the package) and the exception message, I would like to have them apart. This way, it would be possible to handle exceptions without having to dissect the message, making things easier.
Besides, I would love to return the whole exception chain, if in a limited way: just the exception type and the message for every exception in the chain would be enough.
My proposal is to return
serverExceptionwith the error information, that would provide the following entries:
exception.type: the full exception name of the topmost exception.
exception.message: the message of the topmost exception.
rootException.type: the full exception name of the root exception.
rootException.message: the message of the root exception.
exceptions: an array of elements containing the
messagefor all exceptions in the exception chain.
- As always, more tests have been added to help make DJN code more robust.
While I consider this beta to have release quality and pretty safe to use, I prefer to get ample public exposure before promoting it to final.
To download it, go to the DirectJNgine googlecode site.