The Architecture

The following sections are targetted at architects and developers who are interested in using betterFORM in their own applications and give some insights about the inner workings.

System components

This section describes the main building blocks of the betterFORM architecture. This is a bird-eye view of the processor itself and its connections/interactions with the embedding environment.

Client-side JavaScript Gallery

betterFORM can be used in different scenarios but the above diagrams focusses on the most common one: the use of betterFORM as a server-side processor.

The XFormsProcessor lives on the server-side and runs either in a standalone server or as a typical Java web application (WAR file) on top of any web container. On the client-side the Dojo toolkit is used to provide the user interface and handle the communication with the server. The XFormsProcessor represents the implementation of XForms 1.1.

It is wrapped (Decorator pattern) by a WebProcessor class that handles the communication with the client via the HTTP protocol.

On the client the Dojo toolkit is used for the rendering of controls, for creating application-like layouts and for keeping state of the user interface in sync with the server-side XForms document at runtime.

The XForms Processor

The core of the betterFORM XForms implementation is represented by the XFormsProcessor interface. It is implemented in XFormsProcessorImpl. This implementation may be used in any Java application and offers all methods to instanciate and process a XForms document.

With regard to the MVC pattern the XFormsProcessorImpl takes the role of the XForms controller and at the same time acts as a facade to the processors’ functionality.

Once inited, XFormsProcessorImpl holds a reference to a Container instance which is the DOM representation of the XForms document and the model in our MVC architecture. All runtime manipulations on the Container are carried out by dispatching DOM events from XFormsProcessorImpl to the Container through the dispatch() method of the XFormsProcessor. It will take the id of the target element and the eventtype as arguments and feeds an appropriate event instance into the internal XForms DOM.

All other methods are used to configure the processor before calling init() or to shutdown() the processor.

The main integration as a webapplication follows the Decorator pattern and can be found in the WebProcessor class. This class encapsulates the specifics of the Servlet API and allows the configuration of the processor from a web environment e.g. the passing of initlal params.

The UIGenerator

The de.betterform.generator.UIGenerator is an optional component in the architecture of betterFORM. It’s normally found only in server-side integrations though there might be cases where it makes sense on a client too (e.g. when generating print versions of your forms).

It is responsible for transcoding a XHTML/XForms document into XHTML + JavaScript which can be served to browsers that have no builtin XForms support. Currently betterFORM uses XSLTGenerator as an implementation of UIGenerator to handle the transcoding part. It would be possible to use an alternative template language for this task.

Processing Model and Lifecycle

The lifecycle of the processor divides in three phases

  1. At init the processor will setup the given XForms along with all referenced instancedata and build an internal object representation of the XForms document. This will include a representation of the host document along with all models and the UI as well as one independent DOM for each instance defined by the model(s). Additionally each model will build a dependency graph to track validations and calculations. During init phase the event xforms-model-construct, xforms-model-construct-done and xforms-ready are fired as defined by the XForms spec.
  2. After init is done the user interface will be generated and the user starts to interact with the UI to input and manipulate data until all entries are complete and correct. These interactions trigger actions in XForms or set instancedata nodes to new values. The processor will execute all these in conformance to the XForms processing model as defined by the Specification. E.g. some actions require the model to be revalidated to ensure consistency. The processor sends notification events for all changes of the processor state which will be used to update the client.
  3. The processing phase ends when the user submits the form or loads a resource with the ‘load’ action. To be exact this does only happen when a submission is declared with replace=“all“ or the load action was used with show=“replace“. Both options use the current display context to show new content returned from the submission or load respectively. The processor will then call shutdown() on XFormsProcessor to cleanup resources. In the web context all session resources will be clean up additionally.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

%d bloggers like this: