|
|
|
|
|
|
Webflow Components and Concepts
As described in Overview of Webflow, the Webflow mechanism controls the presentation of Web pages as visitors interact with your Web applications. To accomplish this, Webflow makes use of various components, some of which are designed to handle complex tasks like form validation or execution of back-end business processes. This topic first introduces you to all the components that may comprise a Webflow, and includes:
Next, this topic discusses some additional concepts with respect to using the Webflow mechanism, including:
Notes: For information about using the Webflow and Pipeline Editors to work with the components described in this topic, see "Using the Webflow and Pipeline Editors." For information about customizing and extending the Webflow mechanism, see "Customizing and Extending Webflow."
Introduction to Webflow Components
Figure 11-1 illustrates the typical relationships among Webflow components. You can refer back to this illustration as you read more about each component.
Figure 11-1 Typical Relationship Among Webflow Components
Note: Webflow used in portal applications may respond to more events than are shown in Figure 11-1. For more information about portal applications and use of the Webflow mechanism, see Customizing Portlets and Portals in the Getting Started with Portals and Portlets documentation. A Webflow can first be subdivided into nodes and events. A node represents a state in the Webflow. Depending on the node type, there are a number of predefined events that may occur (such as a visitor clicking a link on a Web page). When a particular event happens, the Webflow decides which subsequent node to invoke to continue the flow. This process is referred to as a transition, and is illustrated in Figure 11-2. Figure 11-2 Generic Webflow Transition
As is also shown in Figure 11-2, nodes may be referred to as origin or destination nodes, depending on their location in a transition. For more information about node types, see the next section, Presentation and Processor Nodes. For more information about the events associated with each node, see Events.
Presentation and Processor Nodes
There are two main types of nodes: presentation nodes and processor nodes. Each of the presentation and processor nodes can be used as origin or destination nodes within the Webflow.
As their name implies, presentation nodes represent states in which the Webflow presents or displays something to a person interacting with the Web application. A Webflow must always start and end with a presentation node. The form of the presentation can be:
You can also create extension (custom) presentation nodes for use in the Webflow. For more information about extension presentation nodes, see How to Create an Extension Presentation Node.
In contrast to presentation nodes, processor nodes represent states in which the Webflow invokes more specialized components to handle activities like form validation, or back-end business logic that drives the site's presentation. The processor nodes available for use are:
Input Processors and Pipelines discusses these processor nodes in more detail.
You can also create extension (custom) processor nodes for use in the Webflow. For more information about extension processor nodes, see How to Create an Extension Processor Node.
Note: For more information about creating a presentation or processor node in the Webflow Editor, see How to Add Webflow Components.
Input Processors and Pipelines
Input Processors and Pipelines are the two different types of processor nodes that come packaged with the Webflow implementation.
Input Processors are predefined, specialized Java classes that carry out more complex tasks when invoked by the Webflow mechanism. Input Processors are typically used to validate HTML form data, or to provide conditional branching within a Web page. For example, an Input Processor may contain code that verifies whether a date has been entered in the correct format, as opposed to embedding that code within the same JSP that displays the form fields. Input Processors contain logic that is specific to the Web application, and are therefore loaded by the Web application's container.
Input Processors are embedded in Web pages using specialized JSP tags, which are discussed in Webflow JSP Tag Library Reference. Java/EJB developers report the status of processed form fields back to HTML/JSP developers via the ValidatedValues class, which is discussed in Webflow Validators and Input Processors.
A Pipeline is also a type of processor node that may be invoked by the Webflow. Pipelines initiate the execution of specific tasks related to your business process, and can be transactional or nontransactional. For example, if a visitor attempts to move to another page on your Web site but you want to persist the visitor's information to a database first, you could use a Pipeline. Pipelines contain business logic that may apply to multiple Web applications within a larger enterprise application, and are therefore loaded by the Enterprise JavaBean (EJB) container.
Note: For more information about transactional versus nontransactional Pipelines, see Transactional Versus Nontransactional Pipelines.
All Pipelines are collections of individual Pipeline Components, which can be implemented as Java objects or stateless session Enterprise JavaBeans (EJBs). Pipeline Components are the parts of a Pipeline that actually perform the tasks associated with the underlying business logic. When these tasks are complex, Pipeline Components may also make calls to external services (other business objects).
Notes: For an explanation of the different Pipeline Component implementations, see Implementation of Pipeline Components as Stateless Session EJBs or Java Objects.
For more information about creating an Input Processor or Pipeline in the Webflow Editor, see How to Add Webflow Components.
The Pipeline Session
It is often necessary to keep track of information gathered from your Web site visitors, or to share the data modified by Pipeline Components and Input Processors as a visitor moves through the site. You may also want to access data that is part of a larger enterprise application, or make a process transactional. To accomplish these tasks, the Webflow mechanism makes use of a Pipeline Session.
A Pipeline Session is an object that is created and stored within the HTTPRequest object. The Pipeline Session provides a single point of communication for all Pipeline Components in a given Pipeline. Input Processors also read data from the HTTPRequest and then use that data to create or update Java objects in the Pipeline Session. The Pipeline Session also provides central access and storage for external classes and also has transactional capabilities. For more information about including the Pipeline Session in transactions, see Including Pipeline Sessions in Transactions.
Note: If you have used a prior implementation of Webflow, you may recall that the Pipeline Session used to be stored in the HTTPSession rather than in the HTTPRequest. This has been changed to enhance performance and facilitate clustering.
The Pipeline Session is comprised of many name/value pairs called attributes or properties. Pipeline Components, Input Processors, and external classes act on particular properties that exist within the Pipeline Session, and may also add new properties as necessary. All objects set in and retrieved from the Pipeline Session should be serializable. For more information about serializing objects in the Pipeline Session, see Serializing Pipeline Session Properties.
To get or set a Pipeline Session property within a Web page, you will use the Pipeline Session JSP tags, described in Webflow JSP Tag Library Reference. To work with the Pipeline Session from within Input Processor or Pipeline classes, you will use the provided support methods to access the Pipeline Session directly. For more detailed information about accessing the Pipeline Session using the support methods, see Pipeline Session Internals.
Events
Each node in a Webflow responds to events, which cause transitions (that is, movement from an origin node to a destination node). However, the types of events a node responds to depends on whether the node is a presentation node or a processor node.
As shown in Figure 11-1, presentation nodes respond to the following events:
In other words, when a visitor to the Web site clicks a link or a button, the Webflow responds to that event. A response might be to transition to another presentation node (such as a JSP) or to a processor node (such as an Input Processor to validate visitor-provided form data).
In contrast, processor nodes respond to the following events:
Exceptions occur when an Input Processor or Pipeline does not execute properly, and indicates an error state. (More information about working with exceptions can be found in Error Handling.) Otherwise, these processor nodes return an object that the Webflow can use to continue.
Notes: Webflow used in portal applications may respond to more events than those described above. For more information about portal applications and use of the Webflow mechanism, see Customizing Portlets and Portals in the Getting Started with Portals and Portlets documentation.
For more information about connecting presentation and processor nodes with event and/or exception transitions in the Webflow Editor, see How to Connect Nodes with Event or Exception Transitions.
Namespaces
Although you will generally have only one Webflow per Web application, namespaces allow you to divide your Webflow into a number of smaller, more manageable modules. This modularity may make your development team more productive by allowing individual developers to simultaneously work with various portions of a Web application, without having to worry about naming collisions. For example, a Pipeline Component defined in one namespace can access a variable defined in another namespace, then redirect to a JSP defined in yet a third namespace.
You can have any number of namespaces within a Webflow, but namespaces can only be one level deep. In other words, you can not nest namespaces.
Tip: Namespaces are best defined along functional lines, such as order management, user management, browsing, and so on. This arrangement enables developers to more easily collaborate, once separate portions of the site require integration. You would not typically define namespaces along horizontal lines (that is, Input Processors, JSPs, Pipeline Components, and so on) because this would make development roles/processes too restrictive.
When a Web application's Webflow is divided into namespaces, the Pipeline Session is also subdivided accordingly. Therefore, a Pipeline Session property set in one namespace can be obtained from another namespace, and vice versa. For more detailed information about the Pipeline Session, see Pipeline Session Internals.
Note: You must specify namespaces in a specific way when using Webflow in portal application. For more information about portal applications and use of the Webflow mechanism, see Customizing Portlets and Portals in the Getting Started with Portals and Portlets documentation.
Special Webflow Components
In addition to the Webflow components previously described, there are four Webflow components that perform special functions in a Webflow. These components are described in detail in this section.
The Begin Node
Typically, a begin node is a node designated as the initial entry point or state of the Webflow, which automatically transitions to a presentation or processor node. The begin node is generally a presentation node in the form of a JavaServer Page (JSP).
If a URL does not specify an origin, namespace, or event, the Webflow mechanism looks for a begin node in the default namespace. If one is located, the begin node is used as the starting point for the visitor's interaction with the application. Therefore, although the begin node is optional, we recommend that you have at least one defined in your default namespace.
Note: You specify a default namespace in the P13N_DEFAULT_NAMESPACE context parameter of your Web application's WEB-INF/web.xml file. For more information about this context parameter, see "Setting Up Your Web Application's web.xml File." For more information about how an application's Webflow gets invoked from a URL, see "Understanding How Webflow Is Invoked from a URL."
You can have more than one begin node in a Webflow (one for each namespace). If a namespace specified in the URL has its own begin node, the Webflow will use that begin node before looking for a begin node in the default namespace. You can also use a begin node as a destination node in a Webflow transition.
Note: For more information about designating an existing node as a begin node in the Webflow Editor, see How to Designate or Remove a Begin (Root) Node.
The Root Component Node
A root component node is analogous to the begin node for a Webflow, only it is the entry point into or initial state of a Pipeline. You must have one (and only one) root component node per Pipeline.
Note: For more information about designating an existing node as a root component node in the Webflow Editor, see How to Designate or Remove a Begin (Root) Node.
The Wildcard Nodes
If the Webflow cannot locate a specific presentation or processor node to complete a transition, the Webflow will search for a wildcard presentation or processor node to use as the origin node. Therefore, wildcard presentation nodes and wildcard processor nodes implement default behavior for your Web application. Put another way, wildcard nodes allow you to abstract common functionality and to locate that functionality in a single place in your Webflow. Wildcard nodes are used only when destination nodes are not explicitly defined in the Webflow. You may have one wildcard presentation node and one wildcard processor node per namespace.
Note: If the Webflow must search for a wildcard node, there may be a slight impact on performance, as more processing is involved.
As an example, perhaps you want a link called Help (that is present on every page) to always direct to a JSP containing help information. To do so, you might use a wildcard presentation origin. Further, you might always want exceptions returned from processor nodes to transition to JSP containing detailed information about the error. This could be handled with a wildcard processor node.
Note: For more information about creating a wildcard node in the Webflow Editor (which is done the same way you create regular presentation and processor nodes), see How to Add Webflow Components.
The Configuration Error Page
The configuration error page is essentially a presentation node whose primary purpose is to display debugging information when there is a configuration error in the Webflow. If the Webflow mechanism cannot locate the destination for a transition after exhausting a list of possible choices, the Webflow will instead display the configuration error page you defined. The configuration error page is useful during development, but should never be displayed to visitors of your Web site. That is, testing should ensure that the Webflow configuration is working before your Web application is put into production.
Note: For more information about how the Webflow searches for possible destination nodes, see Webflow Execution Order.
You can have more than one configuration error page in a Webflow (one per each namespace), but are not required to have any configuration error pages if you do not want to. If a namespace specified in the URL has its own configuration error page, the Webflow will use that configuration error page before looking for a configuration error page in the default namespace. Therefore, although the configuration error page is optional, we recommend that you have at least one defined in your default namespace.
Notes: You specify a default namespace in the P13N_DEFAULT_NAMESPACE context parameter of your Web application's WEB-INF/web.xml file. For more information about this context parameter, see Setting Up Your Web Application's web.xml File.
For more information about specifying a configuration error page name for your Webflow in the Webflow Editor, see How to Set the Configuration Error Page Name.
Chaining and Branching with Processor Nodes
Much like you can move from one presentation node (such as a JSP) to another, you can also move from one processor node (such as an Input Processor) to another processor node. In other words, you do not necessarily need to use processor nodes in between presentation nodes. For processor nodes, this movement is called chaining. In a chaining arrangement, the result state of one successfully executed processor node is another processor node.
Another useful technique regarding processor nodes is branching. You can branch on Input Processor nodes based on the value of the object the Input Processor returns. For example, you can code an Input Processor such that one response from a Web site visitor returns one value, and a different response returns a different value. Based on the value of the object returned from successful execution of the Input Processor, you can cause the Webflow to direct to different destination nodes. Similarly, you can branch on Pipelines based on the exceptions it returns. Based on the type of exception thrown, you can cause the Webflow to direct to different destination nodes. (You cannot branch on return values of objects in Pipelines because the Pipeline Components within them return Pipeline Session properties instead.)
Using Webflow Components in Your Web Pages
When you use the Webflow mechanism in your Web application, each of the URLs within that application should be dynamically generated. This is accomplished by using the Webflow JSP tags, described in Webflow JSP Tag Library Reference.
Note: If you used the prior implementation of Webflow, you may recall that dynamic URL generation was formerly accomplished using the createWebflowURL() method of the WebflowJSPHelper class. This method is still available, but it is strongly suggested that you use the JSP tags instead. The only reason you may want to use the WebflowJSPHelper class instead of a JSP tag is in a servlet or wrapper class.
Using Webflow Components with Portals
With a few exceptions, Webflow works the same way in portal Web applications as it does within the rest of the platform. That is, you can use Webflow to coordinate different parts of your portal Web application, enabling code reuse and maintainability.
The Webflow associated with portals are generally not to be edited because it is fundamental to the application logic that makes up the portal platform. Individual portlets, however, can have individual Webflow files assigned to them, allowing practically all Webflow functionality to be applied to a portlet.
For more information, see Customizing Portlets and Portals in the Getting Started with Portals and Portlets documentation.
Webflow Execution Order
As described in Understanding Webflow as a State Machine, Webflow can be thought of as a state machine and as such, can only be in one state at a time. Webflow transitions from one state to another by interpreting URLs, return values, and exceptions. Therefore, to effectively work with Webflow, you need to understand the order in which Webflow searches for a transition. When searching for a transition, Webflow always attempts to resolve transitions with the exact criteria supplied, but if no matches are found, Webflow broadens its search using wildcards and inheritance hierarchies. The way Webflow searches for a valid transition differs slightly for Presentation Nodes and Processor Nodes.
Note: An important, related concept is that Webflow knows nothing of Pipelines; Pipelines are just Extension (Custom) Processors that BEA has created for you. Consequently, Webflow only governs the flow in and out of Pipelines but not within the Pipeline itself. (The transitions that take place inside a Pipeline are governed by the Pipeline engine.) Therefore, the explanation provided in this section only applies to transitions to and from Presentation Nodes (JSP, HTML, servlets, Extension (Custom) Nodes) and Processor Nodes (Input Processors, Pipelines, Extension (Custom) Nodes) in a given Webflow.
Presentation Nodes
For Presentation Nodes, Webflow's search for valid transitions is done in the following manner:
http://localhost:7501/myapp?namespace=order&origin=shoppingcart
.jsp&event=link.help
Webflow tries to resolve to the shoppingcart.jsp Presentation Node, defined in the underlying order.wf Webflow namespace configuration file as:
<presentation-origin node-name="shoppingcart" node-type="jsp">
<wildcard-presentation-origin node-type="jsp">
Note: For more information about the Wildcard Presentation and Wildcard Processor Nodes, see The Wildcard Nodes.
Note: For more information about the configuration error page, see The Configuration Error Page.
Alternatively, if the Webflow does locate the exact Presentation Node or a Wildcard Presentation Node, then Webflow searches for the supplied event under the respective node. Therefore, given the same URL, Webflow searches for the link.help event in the event list, defined in the underlying order.wf Webflow namespace configuration file as:
<event event-name="link.help">
<destination namespace="main" node-name="help" node-type="jsp"/>
</event>
Note: For more information about the configuration error page, see The Configuration Error Page.
Using the Webflow and Pipeline Editors to create Webflows can help identify potential problems with your Webflow and greatly reduce the likelihood of errors. This is because of the Webflow and Pipeline Editors' built-in validation features. For more information, see About the Webflow and Pipeline Editors' Validation Features.
Processor Nodes
Processor Nodes can transition in one of two ways: they can return a Java object or throw a Java exception.
Note: For more information about the Wildcard Presentation and Wildcard Processor Nodes, see The Wildcard Nodes.
Note: For more information about the configuration error page, see The Configuration Error Page.
Using the Webflow and Pipeline Editors to create Webflows can help identify potential problems with your Webflow and greatly reduce the likelihood of errors. This is because of the Webflow and Pipeline Editors' built-in validation features. For more information, see About the Webflow and Pipeline Editors' Validation Features.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|