Opentaps Google Web Toolkit

From Opentaps Wiki
Revision as of 14:46, 26 November 2008 by Jwickers (talk | contribs) (Building GWT)
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.


Client-side security 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 trust security permission to the client side widgets alone. Specifically, it is possible for somebody to hack your JavaScript or JSON objects and add permissions to their session. 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 permission again. Client-side widget security checking is only for hiding parts of the user interface and should not be considered truly secure.