Introduction to Designing Forms

Field. 1

Table. 1

Text 2

Pages and Controls 2

Design Process 2

Programming. 2

Integration. 3

Page Navigation Buttons 4

This document provides an introduction to designing forms and provides a brief outline of some of the functionality available. For more information on any subject, follow the links provided.

Basic Building Blocks

Form-level Objects

The following are form-level objects and can be referred to and changed at any time during form processing.

Field

A field represents a single value. The value might have been obtained by displaying the field to the user, it might have come from an external source such as a database or a Web Service, or it might have been set programmatically. A field can have many attributes e.g. name, value, type, display type.... and many more.

A field can be displayed to the user using a Field Control – note that when a field is displayed, the display type e.g. textarea, checkbox, dropdown etc is a property of the field, not the Field Control..

In the Form Editor, fields are added and maintained in the Fields View.

Table

A table represents an array of values. Each table row consists of a number of columns (which are very similar to fields), and a table can have any number of rows. The table data might be loaded from an external source such as a database or a Web Service, and can also be saved back to the resource. Alternatively, a table might just be used as a temporary working structure in support of the application logic. A table can be displayed to the user using a Table Control.

In the Form Editor, fields are added and maintained in the Tables View.

Text

A text represents a multi-lingual text: at runtime, the appropriate texts are automatically displayed in the runtime language. Each text can be displayed to the user at any point during form processing, and can also be accessed and changed programmatically.

In the Form Editor, texts are usually maintained by double-clicking in the WYSIWYG View or by setting a text property on another object.

Pages and Controls

A page represents an HTML or XHTML page displayed to the user, and each page consists of a number of Controls. A control is any element that can be added to a page e.g. input field, table, menu, text etc.

Within each page, the controls are arranged in a hierarchy where some controls are capable of acting as parents of other controls; these parent controls are called container controls and each one is associated with a layout that defines how its child controls are to be displayed.

Controls are styled using CSS; this is configured by adjusting style properties for each control, and these properties allow the specification of both inline style and CSS classes linked to style sheets. Click here for more information on how forms are linked to style sheets and style is applied to a form.

Within the Form Editor, each page is represented by both the Outline View and the WYSIWYG View – these two views work together. Controls can be added to either of these views in a number of ways, usually by dragging the appropriate icon from the Palette View or by dragging a field or table from the Fields View or Tables View.

Pages are added and maintained using the Pages View.

Design Process

Typically, a form is created as follows:

Link the form to a Presentation Template using the Form Properties dialog (this supplies basic styling)
Link the form to a Business View to provide integration with external resources such as databases using the Form Properties dialog
Create any required form level objects: fields and tables and configure their properties
Add controls to the first page by dragging and dropping objects from the Palette View, Fields View or Tables View
Configure properties for each control as required
Add programming as required
Repeat steps 4 – 6 for any additional pages

Programming

Programming logic is added in scripts, and these scripts are attached to events, where:

Events are points within the processing flow of a form e.g. on click event for a button or hyperlink
Scripts are programs written in Form Processing Language (FPL) which is a scripting language with English-like syntax. A form can only use scripts from the same project or from the GLOBAL project.

Scripts can be used for all kinds of purposes e.g. validating user input, dynamically changing the sequence in which pages are displayed, dynamically changing the properties of any of the elements described above, interfacing with external resources e.g. to read and write from databases, call web services, send emails etc.

The system supports many events, of which the most important are shown below with some typical uses for each event:

Event	Typical Use
Form Events
Before Form	To perform any preliminary processing before the first page is displayed to the user e.g. load information from a database or some other external system.
After Form	To perform any final processing: this might include inserting database records, sending emails. This event is only executed when the user clicks on the optional Finish Button – see page navigation buttons.
On Error	Receives control when a failure occurs. Used to display a customized error page to the user.
Back Button	Receives control when the user clicks the back button.
Page Events
Before Page	To perform any preliminary processing for the page e.g. loading database data, displaying or hiding fields, making fields display only or enterable etc.
After Page	Receives control when the user clicks the optional next page button. Used to perform page level validation or cross field validation.
Previous Page	Receives control when the user clicks the optional previous page button.
Control Events
Validation	To perform validation of data entered by the user.
On Click	Used to perform specific processing when the user clicks something – e.g. a button, hyperlink, image, tab, menu item etc.

Click here for more information on events.

Click here for details of the FPL scripting language.

Integration

Integration with external systems is achieved using external resources and the system supports a number of these: databases, XML, Web Services, email, MQSeries, Custom (Custom Resources are customer-written Java classes). Click here for a summary of the functionality provided by these external resources.

What these external resources all have in common is that they have the capability of interchanging data with Ebase form fields and/or tables. Each resource consists of a number of resource fields/tables, and these can be mapped to form fields/tables. The interchange of data between an external resource and a form is under the direct control of the forms designer and is controlled using a number of script commands e.g. FETCH, UPDATE, INSERT, READ, WRITE, SENDMAIL etc. The framework for handling external resources is shown in the following diagram:

The Business view acts as a logical link between the form and all external resources to which the form has access.

Click here for more information on integration with external systems.

Page Navigation Buttons

The system can optionally provide page navigation buttons on each page, and these can be included by inserting page navigation controls (there are a number of these). This is based around the idea that a form consists of a sequence of pages to be displayed in turn, ending with the user eventually clicking a submit (or Finish button) from the last page in the sequence to commit his/her work. Prior to clicking the Finish button, the user is free to navigate forwards or backwards through the page sequence. This is illustrated in the diagram below:

· The Next Page button is displayed whenever a next page is configured. When the user clicks this button, the after page event for the page is executed.

· The Previous Page button is displayed whenever the user has navigated forwards. When the user clicks this button, the previous page event for the page is executed.

· The Finish button is displayed when no next page is configured. When the user clicks this button, the after page event for the page is executed followed by the after form event.

A number of page navigation controls representing these buttons are available and can be added to pages as required. Alternatively, designers can choose to insert their own buttons to control navigation between pages.

Click here for further information on provided page sequencing and navigation buttons.

Messages

Messages can be generated using the FPL message command. There are two basic types of message:

· error messages are by far the most common type. When a script issues an error message, form processing stops immediately and the page is re-displayed to the user with the error message. The user must correct the error to proceed.

· warning messages are similar to error messages except that form processing will not stop. Warning messages must be acknowledged by the user.

There are a number of options to control the positioning and styling of messages.

(See Working with Messages for more information)

Lists

A list gives the user a choice of selectable values and is normally be displayed as a dropdown, although options are also provided for displaying a list as radio buttons or as checkboxes. A list is defined as a separate entity within the Ebase Designer and can then be associated with any field or table column. Ebase supports 2 types of list:

· A static list contains language dependent values which change rarely or never. An example of this might be title containing English values: Mr, Mrs, Ms, Miss, and French values : M, Mme, Mmle.

· A dynamic list represents a list of values which will be read from a relational database. These lists are not language dependent. To configure a dynamic list, the forms designer must specify the database table(s) and column(s) and optionally the WHERE clause to be used. Ebase supports complex SQL constructs involving views, joins etc. Additional database columns can be retrieved and mapped to form fields. For example it is quite useful to be able to display something meaningful to the user such as product names, and then automatically populate an additional form field such as PRODUCT_ID with a numerical value, which is of no interest to the user, but of plenty of interest to the form designer.

(See Working with Lists for more information)

Components

A component provides a way to create a sharable piece of form functionality. Components are created separately from forms and can then be inserted into any number of forms as required. Subsequent changes to the component can then be deployed to all forms that include the component. A simple example might be an address component which could contain all the usual address fields plus FPL scripting logic to perform a postcode lookup and populate all the address fields from this. Rather than create this in every form where it is required, it can be created just once as a component then inserted into any number of forms.

(See Working with Components for more information)

JSPs

Each form page can optionally be surrounded by 4 Java Server Pages (JSPs) or HTML pages corresponding to top, left, right and bottom of the page. These are commonly used to include content that is common to all pages of a form e.g. company name, logo, images etc. These JSPs can access the form’s state data – fields, tables, pages etc, so it is also possible to create panels containing navigation menus etc.

Printing

Ebase includes a fully flexible print form designer. This allows any number of multi-page print forms to be designed and associated with any given web form. When the user clicks a print button, the corresponding print form is displayed as a PDF and populated with any data entered by the user. The PDF document can also be saved on the server if required, or attached to an email. The print form editor supports a number of advanced features including:

Support for master pages
Support for styles i.e. colours, fonts, sizes etc
Inclusion of bar codes
Inclusion of images
Inclusion of rectangles and lines
Dynamically expanding elements

An alternative approach to printing is to import existing PDF form documents into print resources.