Pageflow and Form Guide

CHAPTER 1

About Pageflows and XForms

This chapter provides an introduction to the use of pageflows and XForms in exteNd Director applications. It includes these topics:

What is a pageflow?

A pageflow defines the flow of control for a set of pages that execute within a single portlet. Each page presents a set of controls that allow for user interaction. For example, the pages in a flow might provide a way for the user to display stock quotes or weather forecasts, or access corporate data such as employee information.

The pages within a flow can use either of the following technologies to define the user presentation:

HTML
XHTML (XForms)

In addition to presenting pages for user interaction, pageflows can perform background processing tasks. For example, a pageflow might invoke a Web Service, access a database, or simply execute code written in Java.

Wizards To facilitate database access, exteNd Director provides tools for creating pageflows that give the user a way to find, display, and modify records in a database. exteNd Director provides the Database Pageflow Wizard to help you create these pageflows. The Database Pageflow Wizard generates a set of forms (XHTML pages that use XForms technology) as well as one or more pageflows that tie the forms together into an integrated user interface.

exteNd Director also provides tools for creating pageflows that invoke Web Services. To help you create these kinds of flows, exteNd Director provides the Web Service Pageflow Wizard. exteNd Director also provides the Composer Pageflow Wizard to help you take advantage of exteNd Composer^TMservices.

Pageflow components

The core of a pageflow application is the process descriptor, an XML file that you create visually using the Pageflow Modeler. A pageflow process, which is the visual representation of the process descriptor, is a branching series of activities and links that models a set of user interactions within a portlet. These are the key parts of a pageflow process:

Process component	Description
Activity	An object that represents a task. An activity can present information to the user and respond to user interactions, or perform background functions that are not visible to the user. For more information on activities, see Working with Activities.
Link	An object that represents a path in the routing logic of the flow. A link points to an activity. Links are what tie the activities in a pageflow together. A link is a single logical path between two activities. A link can also move data between activities. An activity can have multiple source (incoming) links and multiple destination (outgoing) links. For more information on links, see Working with Links.

Process component

Description

Activity

An object that represents a task. An activity can present information to the user and respond to user interactions, or perform background functions that are not visible to the user.

For more information on activities, see Working with Activities.

Link

An object that represents a path in the routing logic of the flow. A link points to an activity.

Links are what tie the activities in a pageflow together. A link is a single logical path between two activities. A link can also move data between activities. An activity can have multiple source (incoming) links and multiple destination (outgoing) links.

For more information on links, see Working with Links.

Pageflow data

A typical pageflow process includes data that is manipulated by pageflow users or program logic. To access data in a pageflow, you use scoped paths. exteNd Director includes a group of predefined scoped paths that are available from the Pageflow Modeler and the Workflow Modeler and through the Scoped Path API.

For more information on scoped paths, see Using scoped paths in a pageflow.

Pageflow engine

The pageflow engine is responsible for executing and managing workflow processes. It uses the process descriptor created with the Pageflow Modeler to:

Create new process instances
Start and stop activities
Execute the link to the next activity

Workflow and pageflow

It is helpful to understand pageflow by contrasting it with the exteNd Director workflow model. Although workflow and pageflow share similar mechanics, pageflow has some distinguishing features, as shown here:

Workflow	Pageflow
Process-based A workflow is a linear business process that might span several days, or even weeks.	Session-based A pageflow is essentially open-ended, and usually shorter (less than an hour) in duration.
Definite starting point Some specific event or condition triggers a process instance. This can be a system-generated event, like a monthly notification, or user-generated, as in a telephone sales transaction.	Designed entry point The entry point is determined by the pageflow itself and is typically not triggered by an external event, unless the pageflow is being used in a workflow.
Multiple users A workflow assumes multiple users are performing discrete tasks at each activity.	Single user A pageflow application is driven by a single user.
Persistent data Instance data must be stored outside the session so that workitems can be passed to subsequent activities.	Session data A pageflow relies on instance data stored in the current session, although the application can access persistent data.
Definite ending point Some specific event or condition ends the process instance. In a sales order transaction, the business process cannot conclude until the customer verifies receipt.	User-controlled exit point The user chooses when to end the session, although some specific action could trigger a workflow.

Workflow

Pageflow

Process-based

A workflow is a linear business process that might span several days, or even weeks.

Session-based

A pageflow is essentially open-ended, and usually shorter (less than an hour) in duration.

Definite starting point

Some specific event or condition triggers a process instance. This can be a system-generated event, like a monthly notification, or user-generated, as in a telephone sales transaction.

Designed entry point

The entry point is determined by the pageflow itself and is typically not triggered by an external event, unless the pageflow is being used in a workflow.

Multiple users

A workflow assumes multiple users are performing discrete tasks at each activity.

Single user

A pageflow application is driven by a single user.

Persistent data

Instance data must be stored outside the session so that workitems can be passed to subsequent activities.

Session data

A pageflow relies on instance data stored in the current session, although the application can access persistent data.

Definite ending point

Some specific event or condition ends the process instance. In a sales order transaction, the business process cannot conclude until the customer verifies receipt.

User-controlled exit point

The user chooses when to end the session, although some specific action could trigger a workflow.

NOTE: Although workflow and pageflow are different types of applications, the Workflow subsystem provides facilities for integrating them. You can embed a pageflow in a workflow using the Pageflow activity in the Workflow Modeler. You can also start a workflow process from a pageflow using a Java activity.

For more information For details on embedding on a pageflow in a workflow, see the chapter on working with activities in the Workflow Guide. For details on starting a workflow process from a pageflow, see Example: Starting a workflow process.

What is XForms technology?

XForms provide a robust, standards-based way to define Web forms. The advantages of the XForms standard include:

Separate data, logic, and presentation modules
A powerful event model (so that you don't have to use a lot of scripting for client-side validation or calculations)
A way to process data in XML formats

XForms cannot run as standalone applications. They are designed to run as components within a host language like XHTML. In the Novell implementation, XForms run within the context of a pageflow application.

XForms structure

A single XForms document includes the sections shown in the following diagram:

XFormsStructure

Section	Description
Model	An element that defines the structure of the XML data used by the form. The Model defines the data that is: Displayed or entered by the user Submitted to the server Used for temporary calculations The Model element might also include rules for validation, constraints, and calculations.
Presentation	The XForms 1.0 Specification defines a set of abstract controls you use to define the user interface. You can bind the controls to data elements defined in the Model.
Events and actions	Defines the form's processing logic. XForms Actions provide built-in logic to run in response to events. Events and actions can be programmed on both Model and presentation elements.

Section

Description

Model

An element that defines the structure of the XML data used by the form. The Model defines the data that is:

Displayed or entered by the user
Submitted to the server
Used for temporary calculations

The Model element might also include rules for validation, constraints, and calculations.

Presentation

The XForms 1.0 Specification defines a set of abstract controls you use to define the user interface. You can bind the controls to data elements defined in the Model.

Events and actions

Defines the form's processing logic. XForms Actions provide built-in logic to run in response to events. Events and actions can be programmed on both Model and presentation elements.

For more information on using the Form Designer to define the Model, presentation, or events for an XForms document, see Form Designer.

Form data

In XForms, the data is defined in the Model element. The Model can contain one or more instance elements.

At design time, you provide the Form Wizard with an XML schema or instance document that defines the structure of the instance data. Once an initial form is created based on this structure, you'll use the Form Designer's Model Editor to define additional information about the data such as constraints, calculations, validations, and so on. In addition, you'll define how the runtime data is:

Supplied—since the form runs in the context of a pageflow, you'll specify the circumstances when the data is supplied by the pageflow (if the instance data is inline).
Submitted—you'll specify what part of the data to submit, and the other submission details such as: the method (PUT, POST, GET) and the encoding.

XForms processing

XForms can be processed via a browser plug-in or a server-side XForms processor.

At startup the exteNd Director portal checks to see if a browser plug-in is installed. If not, XForms processing defaults to the Novell exteNd Director server-side processor. The server-side processor is responsible for:

Generating an in-memory model of the form
Generating HTML and Javascript so that a browser can render an XForm.
Performing the data validation, calculations, constraints and so on defined on the form.
Responding to XML events and XForms actions that occur on the form.

The following diagram illustrates the interaction flow of the Novell exteNd Director server-side XForms processor and a device such as a browser.

XFormsProcessorArchitecture

The browser makes a request for an XForms document—running in a pageflow.
The pageflow portlet receives the request (via the portal container), renders it, and passes it to the XForms server-side processor.
If a browser plug-in does not exist, the XForms exteNd Director server-side processor:
- Builds an in-memory model of the form.
- Renders the form as HTML and Javascript (to render the XHTML in a format that a browser can understand).
- The XForms processor returns the markup fragment to the pageflow portlet.
The Portal returns the markup to the browser.
The browser establishes a network connection to the XForms server-side processor so all subsequent communications within the form (for example, event processing) are direct with the XForms server-side processor, bypassing the Portal container.

About the Pageflow Modeler

Integrated into the development environment is a complete graphing package called the Pageflow Modeler that allows you to quickly and visually create a pageflow process. The Pageflow Modeler allows you to:

Graphically lay out, annotate, and format your pageflow
Create, change, and delete activities and links
Set activity and link properties
Use the Scoped Path Navigator to associate activities and links with data

When you save a pageflow, the Pageflow Modeler translates your document into an XML-based file called a process definition. The process definition saves the layout and format of your pageflow and translates the flow logic into a program the pageflow engine can read and execute.

The Pageflow Modeler also saves a portlet fragment deployment descriptor that maps your pageflow to a pageflow runner. The pageflow runner is a Java class that is implemented as a portlet.

About the Form Designer

The exteNd Director Form Designer provides an environment for developing XForms 1.0-compliant Web forms. The Form Designer is a graphical development tool that allows you to quickly create XForms components for use in pageflow applications.