The gwt-platform Library

One of major requirements of the GWT web app is to use a clean and extensible MVP pattern to build the web app. our research propose the GWT-platfrom library is a good candidate for fulfilling our MVP design pattern elegantly built into this library.

The MVP component is the core of GWTP. It contains a collection of client-side Java classes that lets you organize your application into a loosely connected collection of Presenter-View pairs, following Google's recommended approach.

Note, working version is here

Major strenghts features of GWTP:

*Loose coupling between presenters: There are no direct dependencies between parents and children. All communication takes place over the event bus and the child simply fires an event that a parent presenter reacts to. Want to change parent for a child? You change the event type being fired in the child..that's it. You can also reveal the child in different parents with this based on the context, for example token parameters. Parents annotate defined events with @ContentSlot where child presenters are injected when they fire that event.

*Lazy loading: gwt-platform introduces the concept of light-weight proxies. These proxies listen to events and instantiates your presenters on demand. Your presenter/view is therefore not created until the first request.

*Non-singleton presenters: Singleton presenters does not always make sense. Sometimes you want to re-use presenters in different contexts, and this is where PresenterWidgets come in handy.

*Code splitting: Code splitting could not possibly be easier. You simply annotate your proxy with @ProxyCodeSplit, and the initialization of the presenter is behind a code split point. Incredibly easy and powerful.

*Place management: Easier than ever. With three lines of code and no new classes, you have mapped your presenter to a place. The gwt-presenter problem with quering every place if it's a match is avoided as well.

*Search engine crawling: Integrated support for letting search engines crawl your GWT app (still in experimental phase).

*Integrated command pattern for RPC communication (we don't use server side feature in this project. but this feature is useful in server RPC enabled apps).

The backend: GWT and couchDB integration Design

Ian has already proposed his thoughts about deploying GWT app to counchDB.

In fact what we need is a Good design to encapsulate (abstract) the db access and processing in a package or (better a gwt module?). so that we can call the db access logic from the UI parts easily and cleanly.

gwt-couchdb

I did some research and found the gwt-couchdb project which seems to propose a method to integrate GWT and couchDB in a more clean way. (This needs more study to decide if this tool could be useful for GND project).

Remarks on gwt-couchdb tool:

-it uses GWT rpc to query the couchdb.maybe gnd project doesn't use the rpc mechnism and need to do the couchdb query in another way?

-gwt-couchdb gives some good ideas for encapsulation of the couchdb opertations and provide a comprehensive interface to re-use the db. probably with removing the rpc parts and replacing them with the required method used by gnd we can reuse parts of this tool.

However, the important thing to mention is that Because CouchDB is just a simple REST HTTP endpoint, we don't need special design patterns for integrating with a web framework or anything else. It's just HTTP! Ease of integration is a big part of CouchDB's allure. So maybe we don't need to put big emphasis on the design of this part and probably keep the design already implemented in smartGDN2 project?

Ektorp

Ektorp (https://github.com/helun/Ektorp) . embeds HTTP requests and json marshalling/unmarshalling, and the GWT RequestFactory API. Easy, clean, it's a minimalist stack. You never use json objects but java ones. You can do get/update/etc requests from GWT via RequestFactory.

I can't find any reference to Ektorp with GWT. I'm aware of Ektorp, but had only used it in Java. I don't think its dependencies are met in GWT. Ian 11 Sep 2012

BrowserCouch

this blog entry presents the BrowserChouch javascript couchdb library. The code is here. writing a GWT wrapper for this library could be an interesting project!

This isn't an interface to CouchDb, it's a javascript implementation of a MapReduce algorithm, similar to CouchDb. It does not meet any of the requirements of this project. Ian 13 Sep 2012

jquery.couch.js library

another suggestion is the jquery.couch.js library. It's well commented, and I believe CouchDB's own Futon web application uses it to communicate with the database. You can find the source code here.

other JavaScript library options here

GND GWTP Project package structure

The Document Model Design

Document Model class Diagram

DocumentModel class will holds most operations and data query for the data in Document the class that holds the json data request from couchdb.

The Goal is to implement a clean and reusable DocumentModel class that we can reuse in the project presenters for data processing and persistence.

The jsonp calls to couchdb are delegated to the methods argument of type AsyncCallback. the callback performs the jsonp request to required rest urls. when the model method is called in presenters onBind() the AsyncCallback onSuccess() method receives results and do appropriate processing.

Discussion: Can we have a Base class that does the jsonp async calls and reuse this class in the DocumentModel? the issue is that the jsonp calls are asynchronous so there is no way the DocumentModel class methods returns results b/c the calls are asynchronous. this is why the JSONRequest class is irrelevent . we used the jsonp calls in the DocumentModel methods that all return void and are asynchronous in nature. if the JSONRequest class is irrelevant i need to update the above class diagram.

In fact after thinking more about theis design i think the DocumentModel class name is misleading. It's better to call it something like DocumentJsonRequest . tha's what the class is doing in fact : it does jsonp requets. For the models they are already there : Document and Metadata which are classes that extends JavaScriptObject.

So should we treat the two JavaScriptObject classes Document and Metadata as the models? should we create a class that wrapps these two JavaScriptObject classes? my opinion is that we treat Document class as the Document model. and have the DocumentRequest class do the jsonp async calls. Your thoughts?

Welcome Page Design

we will deal with events using the reversed MVP pattern

we build the view using UiBinder. we rely on css and gwt html technologies to render the view page using UiBinder