Validation in GWT
Client Side Validation:
DTO Class UserDto:
public class UserDto implements Serializable {
private int userId;
private String userName;
}
Remote Service interface:
public interface MyService extends RemoteService {
public String saveUser(UserDto userDto);
}
Remote Service Asynchronous interface:
public interface MyServiceAsync {
public void saveUser(UserDto userDto, AsyncCallback<String> callback);
}
The client side call will be as follows:
MyServiceAsync myService = MyService.Util.getInstance();
UserDto user = new UserDto();
user.setUserId(Integer.parseInt(userId.getText()));
user.setUserName(userName.getText());
myService.saveUser(user, new AsyncCallback<String>() {
…
So when user for example enters string in user id, a number format exception will be raised which can be caught and appropriate error messages can be displayed. For debugging purposes the exception details are displayed in FireBug and the Hosted mode server console. (see GWT documentation for the emulated java exceptions).
Server side Validation:
Invalid input types:
The serialized request sent to the RPC service is mentioned as follows:
http://host:8888/TestValidation/?485975FDB961BEAB5B5D6F881FE9205A?demo.client.MyService?saveUser?demo.client.UserDto?demo.client.UserDto/1050776168?text?1?2?3?4?1?5?6?2342?7?
The dispatcher Servlet uses the interface name and method requested to get the bean implementing the requested interface, by using reflection, it gets the method parameters
By using ServerSerializationStreamReader utility class, it de-serializes the request parameter to the actual method parameter:
ServerSerializationStreamReader.deserializeValue(parameterTypes[i]);
The ServerSerializationStreamReader class, validates the parameters for its compatibility with method parameter types, and create the method parameters. If invalid parameters are sent, a serialization exception is sent back to the client (internal server error (code: 500)
Business constraint violations:
Since GWT handles the incorrect types automatically (String instead of integer for example), the business constraints on data transfer objects should be handled by the service invocation layer (RPC Handler)
- Approach 1:
- Using third party validation party (for example Oval http://oval.sourceforge.net/) which allows defining annotations on the client DTO
- Approach 2:
- Validating the input DTO manually by the service invocation layer
In order to allow third party annotations to be recognized by the GWT Compiler, the library should be included on the class path of the GWT compiler; this ant script illustrates the idea
<path id=”classpath”>
<pathelement location=”${gwtpath}/gwt-user.jar” />
<pathelement location=”${gwtpath}/gwt-dev-windows.jar” />
<pathelement location=”${src.dir}” />
<fileset dir=”${lib.dir}”>
<include name=”**/*.jar” />
</fileset>
</path>
<target name=”compile-gwt” depends=”init”>
<java classname=”com.google.gwt.dev.GWTCompiler” fork=”true”>
<classpath refid=”classpath” />
<jvmarg value=”-Xmx256M” />
<arg value=”-out” />
<arg value=”${www.dir}” />
<arg value=”${gwt.module}” />
</java>
</target>
No comments yet.
Leave a comment
-
Recent
-
Links
-
Archives
- July 2009 (1)
- October 2008 (3)
-
Categories
-
RSS
Entries RSS
Comments RSS