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.
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.
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.
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.
.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).
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
- 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-readyare fired as defined by the XForms spec.
- 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.
- 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
XFormsProcessorto cleanup resources. In the web context all session resources will be clean up additionally.