Skip to end of metadata
Go to start of metadata

This is the application compliance evaluation template which can be used to "grade" how well a web application follows the recommended approaches documented in the GWT Reference Guide.  This template can be completed as part of an ART review and can be used as a tool in that over-arching process.  The goal is to provide as many objective data points as possible and use those data points to improve compliance and consistency going forward.  Clearly, the template and data points will evolve over time, but this should provide a solid basis for the discussions that trigger that evolution.  While scoring something like this can be somewhat subjective, the goal is to provide as objective and quantifiable of an assessment as possible.

For detailed instructions regarding the use of the template, see the Instructions for use child page.

For a completed example, see the Example completed template child page.

NOTE:  Some of the links below are not functioning correctly at the present time.  There appears to be an issue with Confluence and the issue is being investigated.  While the links will take the user to the correct page, it does not always take them to the correct location (anchor) in that page.

CategoryPointsWhat's Specified in the Reference GuideExampleApplication ApproachScoreComments
Project Name5 organization-appname-apptypeemory-webease-webapp   
Project Organization5

Use standard GWT package naming conventions plus extra packages identified in the reference guide.  See Organizing the Project for more information.  Note, bold items in the Example column are the extra packages.  Also, some packages (like the iphone and ipad package) would only exist if they were needed.

 

top-level.client

top-level.client.activity

top-level.client.common

top-level.client.desktop

top-level.client.iphone

top-level.client.ipad

top-level.client.mvp

top-level.client.ui

top-level.client.view

top-level.server

top-level.shared

   
View Implementation Hierarchy10

Use base view interface and super classes for all and device specific views.  See Ancestor view interface and base classes for more information.

 

top-level.client.view.MyView (interface)

top-level.client.view.MyViewImpl (super for all views)

top-level.client.desktop.MyViewImpl (super for all "desktop" views)

   
UI Binder10

Use UI Binder to define views and bind the XML representation of the view to the Java implementation.  See Creating views using UI Binder for more information.

 

top-level.client.desktop.MainViewImpl.ui.xml

top-level.client.desktop.MainViewImpl.java (that extends MyMainViewImplDesktop and implements top-level.client.view.MainView.java interface.

   
Client Factory10

Use client factory implementation to return the appropriate view for the device being used.  Default implementation is "desktop."  See ClientFactory for more information.

 

top-level.client.ClientFactory interface that exposes getters for all view interfaces (e.g., MainView)

top-level.client.ClientFactoryImpl.java (base client factory)

top-level.client.ClientFactoryImplDesktop.java that implements ClientFactory and extends ClientFactoryImpl.  This is the client factory for all "desktop" views.  There would be another implementation for other device targets, e.g., ClientFactoryIPadImpl for iPad specific views.

   
Logic distributed appropriately10

Keep non-view specific logic in the presenters/activities so that logic can be leveraged by multiple devices.  This can be somewhat of a subjective assessment.  The goal here is to make sure any logic that might be needed on multiple devices is NOT implemented in the view implementations themselves.  Rather, that logic should be encapsulated in the Activities (presenters) associated to the view.  See Moving service interaction to Presenter (MVP) and Creating more views, activities and places for more information.

 

    
Navigation10

Activities and Places.  While there may be cases where activities and places aren't needed 100% of the time, the goal should be to use them not only for navigation to other named views but also to maintain a separation between non-view specific logic.  Additionally, by using activities and places consistently, browser behavior (back button) is maintained.  See Moving service interaction to Presenter (MVP) and Creating more views, activities and places for more information.

 

top-level.client.activity.AppPlaceActivityMapper.java

Activity implementation for each place the application needs to navigate to.

top-level.client.place.AppPlaceHistoryMapper.java

Place implementation for each activity.

   
Event Handling10

In the view implementation.  See  event processing for more information.

 

    
Client-Server Interaction10

GWT-RPC.  See Creating the service layer for more information.

 

    
Integration and Persistence10

When an application connects directly to a database, use JPA to handle persistence. ESB services should always be used to consume or provide data from other applications.

See Getting data from backend sources for more information.  TODO:  Expand guide to discuss criteria for making the determination for when to use database vs. ESB services and how to use JPA etc.

 

    
Build and Packaging5

Project should have a build and package environment established on package.cc.emory.edu.  See Central builds for more information.

Note that we are working on developing a new build/deploy system, but need to make sure this system is supported in the meantime until the solution is finalized.

    
Deployment5

The runtime artifacts (.war file) should be deployed to a standard JBoss instance in the appropriate environment (dev, qa, prod).

    
Database Transactions10
  • In general, there should be only one transaction per request unless the business requirements specify otherwise.
  • The JPA API is used for access to transaction management facilities.

TODO:  add section to reference guide

    
Unit Testing / CI10

JUnit should be used for unit testing. Jenkins will ensure that the tests are run with each commit (daily at a minimum). Target coverage for new projects will be as follows.

  • Classes 100%
  • Methods 100%
  • Lines 80%
  • Conditionals 80%

 

 

 

   
Authentication10

All applications with an internal user base (Emory or Emory Healthcare employees and sponsored accounts) should use Shibboleth.

TODO:  provide more information on cases where Shibboleth is not appropriate and the techniques that should be used in those cases.


    
Exposing GWT application's service layer (RPC)
10 (when applicable)
  • REST interfaces are used for exposing the application's service layer for access by other systems. 
  • Jersey 2.6 (last version to support Java 6) is used as the implementation and javax.ws.rs standard annotations are used to define the REST service. Use latest version of Jersey for applications ported to JBoss 6.
  • Authentication is accomplished using client certificate authentication, as per recommendation from the security team.

TODO:  update reference guide (exposing your application's service layer section) to reflect current best practices.

    
Logging5
  • Use log4j on the server side. 
  • Use java.util.logging for the client side.

TODO:  need to do some investigation into this to see what the best approach for client side logging is.  It seems to have changed a bit over the various versions of GWT.

    
Total Grade     % GWTRG Compliance Score

General Comments

This is where the evaluator can add general comments about the application that either add to comments made above or discuss other items that may not be covered in the categories above.

This section allows the reviewers to document action items and assign those tasks to an individual or group to be completed.

Action Item DescriptionAssigned ToDue DateDate CompleteComments
     
     
  • No labels