NetUI Page Flows: An Evolution of Struts
Pages: 1, 2, 3, 4, 5

Advantages of Page Flows

Besides ease-of-use and other benefits that Page Flows offer, here are some important advantages of Page Flows:

• Page Flows are modular: A simple Web application can contain several Page Flows, each handling a portion of logically related functionality. You can use shared Page Flows, or global Page Flows,  to handle exceptions and unhandled actions.
• Page Flows are nestable: Page Flow nesting offers fine-grained, reusable modularity to handle functionality and data.
• Page Flows are stateful: Data management is very easy due to the ability to declare Page Flow-scoped variables.
• Page Flows are annotation driven: Last but not the least, annotation-driven programming is a welcome change, replacing multiple-file, shattered-code programming.

Although this article is only an introduction to the basics, I hope you're getting a feel for how these features can contribute to creating large, manageable applications. The modularity and nesting features are particularly useful in composing reusable Web application components, while features such as session data management and rich data-binding tags contribute to ease of programming.

Integrating Struts and Page Flows

I hope the previous section has convinced you that Page Flows are a useful extension to Struts. Let's now look at ways in which you can add Page Flow functionality to existing Struts projects, or have Struts and Page Flow applications interoperate.

Page Flows are built on top of Apache Struts 1.1. Each Page Flow is compiled into a Struts module. As a result, Page Flow and Struts 1.1 applications can work closely together.

There are two approaches to using Struts components in Page Flow applications:

1. Struts interoperability: Use Struts components directly in Page Flow applications.
2. Struts merge: Import simple Struts applications into new Page Flow applications.

Integration: Struts Interoperability

The Struts interoperability feature uses existing Struts-based components without modifying them. This allows existing Struts components to interact with Page Flow components and leverage existing JSP pages, action classes, forms beans, and flow configurations.

Struts and Page Flow applications can live and interact with each other inside a Web application. To forward from a Page Flow to a (pure) Struts module, simply reference the desired action within the Struts module. The same goes for the reverse direction: From a Struts module, simply configure an action to point to the desired method in the Page Flow.

A Page Flow can act as the front controller that processes the initial request and then passes the control over to actions within Struts that then do some processing and transfer control back to Page Flow. A similar pattern can be observed in nested Page Flows. Form beans can also be shared among Struts applications and Page Flows in these ways:

• In a Page Flow you can import and use form beans defined by Struts 1.1 modules. So you can take advantage of existing Struts code quickly, without having to make modifications in Struts action classes and form beans.
• In Struts 1.1 action classes, form beans defined by Page Flows can be imported and used.

The files that comprise Struts modules and the Page Flows, if they are to interoperate, must exist in the same Web project.

Requirements of the Struts modules and Page Flows

Here are the requirements of Struts modules and Page Flows that will interoperate with each other in the same Web project:

• The existing Struts should be version 1.1.
• The files that comprise the Struts module must reside in the same Web project as the Page Flow.
• All compiled Struts-related classes (bytecode) that are in a JAR file must reside in the WEB-INF/lib directory.
• To avoid naming conflicts, the Struts module names and the Page Flow directory names must be unique across the Web project.
• The JSP pages that reside in a Page Flow directory always render in the Page Flow JPF context. JSP pages that invoke actions and render in the context of the Struts module should go in another directory, such as in <project-root>/strutsModule.
• If a Page Flow controller class and the Struts action classes share a form bean, the form bean can be defined as either an inner class or as an external Java file. Import the form bean class in the Page Flow JPF and the Struts action classes that will use it.
• When a form bean is shared, in the Struts module's XML the value of the <form-bean name=...> attribute must match exactly the value of the name attribute generated in the Page Flow's jpf-struts-config-<pageflow-name>.xml file.
• By default, Page Flow scopes form bean instances to the request. The easiest way to share data is to pass session-scoped form beans between Struts and Page Flows. This can be accomplished by using the Struts merge feature to merge in session-scoped form beans with the Struts configuration XML that will be generated for the Page Flow.
• If a Web project combines Page Flows and Struts modules, each Struts module must be registered by editing the project's /WEB-INF/web.xml file.

An interoperability example

This example shows how Page Flow actions can call Struts actions and vice versa. The purpose of this example is simply to show interoperability, and so the code is not complete. PageFlowActionA passes control, along with session-scoped form bean, over to StrutsActionA. StrutsActionA does some processing and forwards to Page.jsp which has a Struts action, StrutsActionB. StrutsActionB passes control back to PageFlowActionB.