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.
|Category||Points||What's Specified in the Reference Guide||Example||Application Approach||Score||Comments|
Use standard GWT package naming conventions plus extra packages identified in the reference guide. Seefor 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.
|View Implementation Hierarchy||10|
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.MyViewImpl (super for all views)
top-level.client.desktop.MyViewImpl (super for all "desktop" views)
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.java (that extends MyMainViewImplDesktop and implements top-level.client.view.MainView.java interface.
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 appropriately||10|
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.
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.
Activity implementation for each place the application needs to navigate to.
Place implementation for each activity.
In the view implementation. See event processing for more information.
GWT-RPC. See Creating the service layer for more information.
|Integration and Persistence||10|
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 Packaging||5|
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.
The runtime artifacts (.war file) should be deployed to a standard JBoss instance in the appropriate environment (dev, qa, prod).
TODO: add section to reference guide
|Unit Testing / CI||10|
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.
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)|
TODO: update reference guide (exposing your application's service layer section) to reflect current best practices.
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|
|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 Description||Assigned To||Due Date||Date Complete||Comments|