When initializing the main servlet of VDoc, the first object is created. It is named com.axemble.vdp.ui.framework.foundation.Application.
This object is the central point for sharing elements between every HTTP sessions.
When receiving the first request from a web browser, the system will create an object named com.axemble.vdp.ui.framework.foundation.Navigator and associated to a browser. It represents the web browser on the server.
This Navigator object will be available during all the HTTP session life and will be accessible for all client web/server exchanges.
When receiving the request, an object of context is created. It corresponds to the "execution context".
This object, available for all the HTTP request duration, implements the interface named : com.axemble.vdp.ui.framework.runtime.IExecutionContext.
A Java interface is used because the VDoc system needs to work in the same way in both environment JBoss and WebSphere Portal Server (servlets containers for JBoss and portlets for WebSphere Portal Server). Indeed, the IExecutionContext interface contains a lot of common methods for HTTP objects of these both containers types.
The ExecutionContext object enables to access to two elements types coming from the dynamic context. It maintains HTTPS objects as :
It contains also information linked to the execution in VDoc context. From this object ExecutionContext the following objects are accessible :
The VDoc system inspects the parameters passed in the URL and requests the Navigator object to build a screen implementing the interface named com.axemble.vdp.ui.framework.foundation.screens.IScreen. This screen object (Screen) maintains a unique browsing object implementing the interface named com.axemble.vdp.ui.core.providers.INavigationListenerImpl. This browsing object which represents the displayed screen, is based on a template.
Screen templates are needed to build the graphical interfaces. Several standard templates are available:
These templates enable the typed-creation of web screens and the handling of available elements as buttons,tabs,fields entries.
Example
The code below builds a simple form composed of a header, a footer and a content zone in which there are two TextBox fields.
// new screen creation
IScreen screen = new Screen();
// creation of a form based on a simple template
CtlForm fooForm = new CtlForm(“fooForm”);
fooForm.setLabel( new CtlText(“Form title”) );
fooForm.setInformation(new CtlText(“Form description”));
// adding fields entries. Each entry is composed of
// a title and a graphical component (CtlTextBox, CtlDate, CtlComboBox, etc.)
fooForm.addEntry( “fld_1”,
new CtlText(“fldLabel_1”),new CtlTextBox(“fld_1 value”) );
fooForm.addEntry( “fld_2”,
new CtlText(“fldLabel_2”), new CtlTextBox(“fld_2 value”) );
// position of the form as the main component of the screen
screen.setRootWidget( fooForm );
// position of the current screen of the navigator
Navigator.getNavigator().setCurrentScreen( screen );The execution of this code creates the following screen:
The VDoc screens are composed of a number of graphical objects such as the header,the footer and a "dynamic" content zone. This "dynamic" zone is built from aroot component.
In most of VDoc screens, the root component corresponds to one of the following classes:
Generally, every class prefixed by "XML" and implementing the INavigationListenerImpl interface can be built from an XML definition document.
In reality, several XML definition documents can be created (declared). They are all merged when loading the server or when refreshing from the Process management administration (Configuration).
The following diagram presents the main objects which allow to implement the VDoc navigation .
This XML definition document is located under the folder « vdoc.ear/vdoc.war/WEB-INF/storage » of the VDoc application. It is named « definition.xml ». It contains the whole XML description of the screens from VDoc application. This definition is valid and global to the VDoc server.
In this XML file, each screen is identified by the attributes « name » and « action ». When a request is processed on the server, the parameters « class » and « method » are assigned. These parameters are compared to the attributes « name » and « method » of the screen and the retrieved screen is built.
Example
The following request http://localhost:8080/vdoc/process?class=DEMO&method=action1 causes the reading of the XML element presented as below (part of the customized XML definition document) and the building of the identified screen, based on the associated template. In our example, the template associated to the "form" tag is a simple form. The final screen will be built with two TextBox fields.
<form name=”DEMO” action=”action1” label=”LG_VIEW_PROP” information=”LG_PUT_VIEW_INFO” provider=”com.axemble.education.providers.demo.DemoFormProvider”>
<fields>
<field name=”fldLabel_1” label=”LG_LABEL1” ctrl=”com.axemble.vdp.ui.core.document.fields.TextBoxField” mandatory=”false” />
<field name=”fldLabel_2” label=”LG_LABEL2” ctrl=”com.axemble.vdp.ui.core.document.fields.TextBoxField” mandatory= »false » />
</fields>
</form>Once the screen is built, the VDoc navigation system provides a way for the developer to interact with the screen. It provides an object called "provider", implementing the interface com.axemble.vdp.ui.core.providers.IProvider. With this object the developer can either fill-in the fields or interact with the user interface. .
The association between the "provider" object and the screen is created via the "provider" attribute in the screens XML definition file. Each provider is specific to the the kind of screen.
Hierarchical relations between all "provider" interfaces
[IProvider]
[IDocumentProvider] – gestion des documents génériques (GenericDocument)
[IFormProvider] – management of simple forms
[ISheetProvider] – management of form with tabs
[IProcessDocumentProvider] – management of process documents (CoreDocument)
[IWizardProvider] – management of wizards
[IExplorerProvider] – management of explorer-type screens
[ILauncherProvider] – management of the right part of the explorer screen
[IViewProvider] – management of every views
[IFilterableViewProvider] – management of views with filters
[IPortletProvider] – management of portlets
[IJspProvider] – management of screens based on JSP
[ISelectorProvider] – management of selectors