Documentation:Developer:Forms:Modelization
From SIDE-Labs.org
Contents
|
Overview
This chapter explains the modeling general principles of form and the generation methods which are provided through SIDE to deploy the generated web form components into your application. The goal of the Form modeling is to allow shaping the input forms which must be used in your application independently of the technical platform which will be used to run your application. Essentially, SIDE provides 2 successive methods to model and generate forms components:
- The first steps starts from the Data (or content) model which may be extended with Forms design elements; with or without these Forms extension, a default web forms on each object may be generated on several frameworks. Obviously, this default form contains all the attributes of each data class in predefined format.
- The second step starts from the Forms design and binds the object to the Forms design elements. In this case, several specific web forms on each object may be generated on several frameworks.
SIDE provides the Model to Model transformations which allow going from one method to the other.
Methodology
The classical design, development and deployment procedures are as follows:
Figure 2.1. Design and Development steps of Forms
In the above figure, the steps are:
- Design the Requirement model: this step consists to write the main requirements of the application, to define the handled objects and to link this requirement to the objects. . This first step is targeted for functional persons: at this level they may generate samples of request for proposal and quotation, tasks description per roles, mind map based specification, high-level functional testing plan.
For instance, this modeling step may be used to draw the functional process of a paperless workflow. - Transform Requirement model into data model: this step consists in applying a Model to Model transformation using a predefined SIDE generator in order to produce the default Data model associated to your application.
- Design the Business Data model: this step consists to draw the Data diagram which describes the objects of your application, their attributes and their associations. Typically for an ECM application you want to generate on Alfresco, this relates to the new content types you want to manage under Alfresco.
- Transform Business Data model into Form model: this step consists in applying a Model to Model transformation using a predefined SIDE generator in order to produce the default Form model associated to your application. This step is practically made directly through the form modeler by creating a form model, inserting a new Form Collection element, loading the concerned data model and synchronizing the Form Collection element with the data diagram elements.
- Design the Form model: this step consists to refine the graphical Form model by specializing the default form model and/or adding other forms which will be deployed in your application.
- Transform Form model into XForm model: this step consists in applying a Model to Model transformation using a predefined SIDE generator in order to produce the XForm templates associated to your application and to produce a first level of code on a targeted framework like Chiba or Orbeon which can be customized. SIDE also provides a generator of Alfresco forms directly deployable on Alfresco Explorer and/or Alfresco share.
- Customize generated Forms: this step consists in customizing the generated code through the addition of Xforms templates extensions.
- Transform XForm template to Form model: this step consists in reversing a XForm-based form in the Form model. This step is useful when customization has been done during previous step and the Form model must be updated to be conformed to the generated Form components. Current release of SIDE does not support this reversing mechanism.
- Transform Form model to data model: this steps consists in reversing a Form model in the data model. This step is useful to have a first level of data model to refine from existing XForms templates and is useful when customization has been done of the Form model during a previous Xforms to form transformation. Current release of SIDE does not support this reversing mechanism.
The steps 1, 3 and 5 are achieved through graphical modeler. The steps 2, 4 and 6 are automatic from a graphical pane and need only to be started : SIDE provides the generators to produce the targeted artifacts but also the “deployers� to directly deploy the artifact on the targeted frameworks. The step 7 must be made by the developer but is usually not necessary as the generators support the last XForms model and the main extensions of the web form engines. A classical path, for instance to propose web forms for filling up official or legal papers (paperless or e-administration workflow), is through the steps 1, 2, 3, 4, 5 and 6. During evolution of the web forms, only the steps 5 and 6 are usually necessary.
Form Model
This chapter explains the modeling of form using a domain specific form model. This approach allows far more flexibility than through the Data model.
Overview
In this approach, we design the Form model using the SIDE Form Meta-model given in Annex A. This modeling work may be made using any modeler able to understand the Ecore-based Form Meta-Model. In the following of this manual, we will use the Eclipse-plugin SIDE Modeler to show instances of model.
Meta-Model Description
At very high level view, the Form meta-model defines 3 main parts:
- The form container to give overall structure (FormContainer, FormGroup, ...) and kinds of form (FormClass, FormWorkflow, ...)
- The form fields to give the input and action fields (TextField, DateField, ...)
- The form association to link the form fields to data attributes (ClassReference, ModelChoiceField, ...)
Some of the elements of the meta-model are associated to operations which may be activated under the modeler: these operations are not described in the meta-model but only at the level of the modeler configuration. For instance, The 'Transform to URLField' operation on a TextField allows to transform the TextField input field into an URL input field. Some of the elements of the meta-model are associated to constraint validation rules using the OCL language: these rules are checked by the modeler before generation or explicitly when the user activate the 'validate' operation through the right click modeler menu. For instance, the 'No Special Characters' is set up on 'id' attribute to prevent the input of special character in the identifier of element of a model a user is creating under the modeler. Note: The Form components managed by the Form meta-model are based on the form elements defined in the XForms 1.1 W3C recommendation (2007-11-29). The table given in Annex A describes all the elements of the Form Meta-model (this is a table generated by a transformation applied on the meta-model and formatting may differ a little of the current document).
Diagram Creation
Practically, in the current release of SIDE, the starting point of the form modeling is the data or workflow modeling. Data or Workflow Models are not used to model forms but they contain the data description on which will be based the form modeling. It is also important to note that:
- Class or task properties parameters may affect the default initialization of form modeling.
- Some form generators may generate default form from the data model referenced by the form models they used for generation.
The first thing to do when creating a form model is to reference the data models which contains the data description on which will be based to form modeling. The next steps is to create a form class or form workflow and to reference the class or task on which will be designed the form. Then, to initialize the form using the action “Initialize from class�: this action will populate the form with the class/task attributes. The properties of each attribute will be used by this action to set up properties of the form like the data type is used to define the default widget. So, refer to the SIDE Data Modeling User Guide for description about these properties.
Main Steps
The form modeler is a tree modeler: the tree structure allows to access all the elements defined in the Form Meta-model in a control way. The general synopsis is:
- Create a SIDE Form model (File -> New -> SIDE Form Model)
- On the 'Form Collection' element, right click and select 'Load Resources' in the menu; in the popup, select the Data model on which you want to work to produce Forms
- On the 'Form Collection' element, right click and select 'New -> Form Class' in the menu; A Form Class is inserted and you can set up the associated data class by updating in the property view, the attribute 'Real Class' (use the selector to choose the class in the class model).
- On the 'Form Class' element, right click and select 'Initialize from class': all the elements of the data class are automatically inserted under the Form Class as Form Fields and can be updated/suppressed to shape the targeted form.
- In the case of association, you can choose to expand the form of the associated data class inside the current form (we speak about 'Inline form' when the form is generated inside another instead of 'Select form' when an association widget is proposed): Richt Click on the Association and select 'Relation -> Expand to -> <data class label>'; this operation will mark the association as 'Expanded'
and a form on the associated data class will be created.
Note: to come back to a Select mode (not Inline), Right Click on the Association and select 'Relation -> Collapse to Model Choice Field'. - After expanding a form, you can drag & drop a field of the form to put it in the embedding form: in this case, the field in the embedding form is labeled as virtual Field.
Figure 3.1. Form model in Form modeler
Figure 3.2. Form commands of Form modeler
Modeler Description
Commands
The following table explains each of the Form commands. Note that the commands which are not in this list are explained in the SIDE Concept and Starting User guide and are common to all the modelers.
Copy From
Description
This command allows synchronizing the form elements with the associated class models which have been updated.
This command is useful when an associated class model has been updated and the updates must be propagated to the form elements. This command uses a model to model transformation to propagate the updates. Refer to the following paragraph to have in depth explanation of this transformation.
Constraints
All the form elements are concerned by the synchronization; in particular, it is not possible to limit the synchronization to a single form class.
Concerned elements
Form Collection, Workflow Form Collection
Group in a New Group
Description
This command allows to create a 'Form Group'. The Form group may then be populated by dragging and dropping other attribute fields.
To complete this action, it is necessary to drag and drop the attribute field which will have a specific presentation in this group and to choose the mode of presentation by setting the 'Presentation' property of the group through the Properties View.
Constraints
There is no limit at the imbrications of group in the modeler but most of the generators does not support more than one level of groups.
Concerned elements
All attribute Fields
Initialize from Class
Description
This command allows initializing a form class with all the attributes of the associated class as form fields.
Before running this command, it is necessary to associate the form class with a class through the setting of the “Real class� attribute in the Properties View (command “Show Properties View�). After running this command, the form class contains one form field per data class attribute and class association.
Concerned elements
FormClass
New Child
Description
This command allows adding a child element under the current element.
The list of the proposed children is contextual and depends of the current element.
Constraints
If the current element does not have child, this menu item is not proposed. If the current element has child but the list of child is predefined and fixed, this menu item is not proposed: this is the case for Form Class where the list of child is predefined by the list of attributes and associations of the associated data class.
Concerned elements
FormCollection, WorkflowFormCollection
New Sibling
Description
This command allows adding a sibling element at the same level in the form tree than the current element.
The list of the proposed children is contextual and depends of the current element.
Constraints
If the current element does not have sibling, this menu item is not proposed. If the current element is part of a predefined element list, this menu item is not proposed.
Concerned elements
FormClass,FormWorkflow
Refresh Outline
Description
This command allows displaying and refreshing the form outline for a form class.
The form outline is an example of generation.
Constraints
All the form elements are concerned by the synchronization; in particular, it is not possible to limit the synchronization to a single form class.
Concerned elements
FormCollection, WorkflowFormCollection
Restore
Description
This command allows inserting an attribute which has been previously removed of the form class.
The restored attribute field is inserted at the end of the form class. It can be positioned by simple drag & drop.
Concerned elements
FormClass,FormWorkflow
Synchronize with Class diagram
Description
This command allows synchronizing the form elements with the associated class models which have been updated.
This command is useful when an associated class model has been updated and the updates must be propagated to the form elements. This command uses a model to model transformation to propagate the updates. Refer to the following paragraph to have in depth explanation of this transformation.
Constraints
All the form elements are concerned by the synchronization; in particular, it is not possible to limit the synchronization to a single form class.
Concerned elements
FormCollection, WorkflowFormCollection
Transform
Description
This command allows transforming an attribute field in a new type.
This command is mainly useful for attribute of type String which wears a particular semantic to take into account as input fields. For instance, the attribute of type string may be an email: the transformation to an email field will allow checking the syntax of the entered value.
Constraints
The interpretation of the format may differ according to the various targeted form framework.
Concerned elements
String, Char fields
Data/Form M to M Transformation
This chapter explains the ways to pass from a data model to a form model and the reverse.
Data fo Form Cheat Sheet
Currently, there is no transformation of a data model to populate a form model as this may conduce to huge form models with all the forms of all the designed content types and this will not be very useful and not exploitable. We choose to use data to form 'model to model' transformation but from the form model and only for a single data:
- First, the designer creates a form model
- He then creates a form collection and then a form class
- He then associates the form to a data class of a data model
- At last, on the form class, he activates the “Synchronize with Class diagram� operation to populate the form class with the fields associated to all the attributes and associations of the data class. In other terms, this operation applies the data to form Model to Model transformation for the concerned data class.
Data to Form Transformation
The Data to form transformation is performed through the “Synchronize with Class diagram� operation of the form modeler. When the data model is updated, use this operation to propagate the updates to the form model. Nevertheless, the updates have a limited scope as described below:
- New attribute (in Data Diagram) are added to the form.
- Deleted attribute (in Data Diagram) are removed from the form.
- Attribute which have been put as mandatory (in Data Diagram) will be put in form if they have been deleted in field's form.
- If an attribute (in Data Diagram) has changed its type (eg : String to Date) the corresponding field nature will be changed.
Form to Data Transformation
The current releases of SIDE do not propose to transform a form model to a data model. This will be provided in next release with the reverse engineering feature.
