Opentaps Google Web Toolkit

From Opentaps Wiki
Revision as of 14:58, 26 November 2008 by Jwickers (talk | contribs) (Security)
Jump to navigationJump to search

Building GWT

The Google Web Toolkit (GWT) is built independently of opentaps. To build the Google Web toolkit widgets,

$ ant gwt

To clear the previous build,

$ ant clean-gwt

This will cause ant to look for look "gwt" in the opentaps components' build.xml files and build them one at a time. In the component build.xml, the following directories are specified for building gwt:

        <property name="gwt.deploy.dir" value="./webapp/crmsfagwt"/>
        <property name="gwt.module.base" value="org.opentaps.gwt.crmsfa"/>
        <property name="gwt.src.common" value="../opentaps-common/src/org/opentaps/gwt"/>
        <property name="gwt.src.base" value="./src/org/opentaps/gwt/crmsfa"/>

Then, when ant tries to build gwt, it will look all that gwt modules specified in the build.xml. Each module is specified at a path of ${gwt.deploy.dir}/${gwt.module.base}.${module}.${module} For example, if you specify contacts as the module to compile, then opentaps will try to compile org.opentaps.gwt.crmsfa.contacts.contacts.gwt.xml, which should be in your src/ path.

When you have an additional GWT module to build, add it to the list of modules:

     <foreach list="contacts,accounts,leads,partners" target="gwtcompile" param="module"/>

To speed up the build during development, you can setup GWT to only compile for one of the supported browsers. This is configured in the common module in hot-deploy/opentaps-common/src/org/opentaps/gwt/common/common.gwt.xml. For example, you can enable it for only Mozilla/Firefox by setting the user.agent property to "gecko1_8":

 <set-property name="user.agent" value="gecko1_8"/>

Configuring Server Side Interaction

Your GWT widgets will need to interact with server-side services to store and retrieve data. A "best practices" pattern we have started in opentaps is to create a configuration Java file for each server side service available for GWT client-side widgets. For example, there is a org.opentaps.gwt.crmsfa.contacts.client.form.configuration.QuickNewContactConfiguration Class which contains the server-side URL and all the form parameters for interacting with the quick new contact service on the server. This is part of the GWT client package and is designed to be used by all the client-side widgets. Note that the pattern is to have one Configuration Java file for each server-side service, to be shared by many client-side widgets which may access the same server-side service, not to have a configuration file for each client-side widget.


The GWT widgets do not perform security checks, but users permissions are made available to them in order to adapt the user interface accordingly. The real security checks allowing a user to perform an operation or retrieve data are performed server side.

Client-side permission checking is handled in the following way:

  1. The server side uses the User object to determine what permissions the currently logged in user has and puts it into the webpage sent to the client as an object using JavaScript. This is done in the main-decorator.bsh and header.ftl of the server.
  2. On the client-side, the Permission class retrieves the security permissions set into the browser via JavaScript. Your GWT widget can use its hasPermission method to check if the user has permissions to access certain sections of your page:
        if (!Permission.hasPermission(Permission.CRMSFA_CONTACT_CREATE)) {

WARNING: Do not rely on those checks to hide sensitive data or services from a user. Specifically, it is possible for the end user to modify the JavaScript add permissions for their displayed widgets. Therefore, you should always filter out sensitive data before sending them to the client-side widgets, and every operation on the server side should check permissions again. Client-side widget permission checking is only for hiding parts of the user interface and should not be considered a security feature.