Enterprise web applications today can easily contains hundreds, if not
thousands of pages. These pages should not only look great visually, but
also offer services to customers that require the implementation of complex
business logic. Managing a complex web site can be a daunting task,
especially where the business logic is implemented directly in the web
pages, and changing the logic requires many edits in many locations.
WebLogic Workshop provides you with the tools to manage complex web
applications using JavaServer Pages (JSPs) and Page Flows.
A D V E R T I S E M E N T
Separation of
presentation and business logic allows for modularity of business logic
implementation, such that the impact of changing business logic can be
minimal. Furthermore, this separation allows the application developer to
concentrate on implementing the business process using Java controls and
EJBs, while the web developer can focus on the presentation. Page flows
provide the navigational control, allowing a web application architect to
easily design the flow between the JSP pages in the web application.
Guide to Building Page Flows
WebLogic Workshop provides you with the tools to develop web applications
using JavaServer Pages (JSPs) and Page Flows, separating presentation,
business logic, and navigational control to manage complexity. The topics in
this section discuss these concepts and provide detailed information on how
to use WebLogic Workshop to develop web applications based on page flows and
JSP pages.
Why Use Page Flows?
By using page flows, you can avoid making the typical mistakes that often
happen during web application development, by separating presentation,
business logic implementation, and navigational control. In many web
applications, web developers using JSP (or any of the other dynamic web
languages such as ASP or CFM) combine presentation and business logic in
their web pages.
As these applications grow in complexity and are subject to continual
change, this practice leads to expensive, time-consuming maintenance
problems, caused by:
Limited reuse of business logic
Cluttered JSP source code
Unintended exposure of business-logic code to team members who focus
on other aspects of web development, such as content writers and visual
designers
Page flows allow you to separate the user interface code from
navigational control and other business logic. User interface code can be
placed where it belongs, in the JSP files. Navigational control can be
implemented easily in a page flow's single controller file, which is the
nerve center of your web application. A controller file is a special Java
file that uses a JPF file extension. Business logic can be implemented in
the page controller file, or in Java controls that you call from JPF files.
The separation of presentation and business logic offers a big advantage
to development teams. For example, you can make site navigation updates in a
single JPF file, instead of having to search through many JSP files and make
multiple updates. In WebLogic Workshop you can as easily navigate between
page flows as between individual JSP pages. This allows you to group related
web pages under one page flow, and create functionally modular web
components. This approach to organizing the entities that comprise web
applications makes it much easier to maintain and enhance web applications
by minimizing the number of files that have to be updated to implement
changes, and lowers the cost of maintaining and enhancing applications.
Another advantage of page flows is that an instance of the page flow
controller class is kept alive on a per-user-session basis while the user is
navigating within the scope of the page flow. This instance ends when the
user exits from the page flow. You can use instance member variables in page
flow classes to hold user session state.
For more information about the advantages of page flows, especially in
comparison to "pure Struts" applications, see
Advantages of
Using Page Flows.
How Does a Page Flow Work?
A page flow is a Java class, called the "controller" class, that controls
the behavior of a web application through the use of specially designed
annotations and methods. The directory that contains the controller class
also includes the JavaServer Pages (JSPs) used in the page flow. For a JSP
to be considered part of a page flow, it must reside within the page flow
directory. The JSP files use special tags which help bind to data and
business logic actions. The action methods in the controller file implement
code that can result in site navigation, passing data, or invoking back-end
business logic via controls. Significantly, the business logic in the
controller class is separate from the presentation code defined in the JSP
files.
The overall purpose of a page flow is to provide you with an easy-to-use
framework for building dynamic, sophisticated web applications. WebLogic
Workshop provides graphical and code-level tools to simplify the development
cycle. While page flows give you access to advanced features of J2EE, you do
not have to be a J2EE expert to quickly develop and deploy Java-based
applications built on page flows. Wizards can be used to create different
types of page flows, generating the Java and JSP files that serve as a
starting point for your work. Graphical tools let you draw the relationships
between web components in a controller's Flow View. In Source View, syntax
completion, validation, and other programmer's aids reduce the amount of
work required to get your application running.
Note: WebLogic Workshop's web
application functionality is built on Struts, which is an open-source
framework for building web applications in a J2EE environment.
Components of the Page Flow Programming Model
Page flows implement user interface control logic, and contain:
Action Methods
Form Beans
Forward Objects
The Tag Library
Action Methods
In the controller class, action methods are methods that are annotated
with a @jpf:action tag.
Action methods can perform several functions. They can (1) implement
navigation decisions, (2) move data into and out of JSP pages, and (3)
invoke back-end business logic via calls to controls.
Form Beans
Form Beans are Java data structures that correspond to HTML forms. When a
user submits data from an HTML form, the data is stored in a Form Bean instance.
Once the data is stored in a Form Bean instance, the data is available for
processing by the action methods in the controller file. Form Bean instances
(containing submitted data) are typically passed as parameters to action
methods.
/**
* @jpf:action
*/
protected Forward ProcessData( MyFormBean form )
{
//Submitted data is processed here...
}
Form Beans are simple Java classes contained within the controller file. They
consist of some number of fields with setter and getter methods associated with
those fields. Below is a Form Bean with one field, the String
name, and setter and getter methods for that
field. Form Bean must extend the class
com.bea.wlw.netui.pageflow.FormData.
public static class MyFormBean extends FormData
{
private String name;
public void setName(String name)
{
this.name = name;
}
public String getName()
{
return this.name;
}
Forward Objects
Forward objects are returned by action methods. They can be used to control
navigation and pass data throughout the application.
The Tag Library
The tag library contains JSP tags specifically designed to work with
the controller class. Tags in the library all begin with the prefixes "netui",
"netui-databinding", and "netui-template". Some of these tags perform much like
familiar HTML tags, while others perform function particular to page flow web
applications. The most important feature of the tag library is its ability to
"data bind" to data in the controller file. Data binding allows the JSP pages to
both read from and write to Java code in the controller class. This is
accomplished without placing any Java code on the JSP pages, greatly enhancing
the separation of data presentation and data processing.
Flow, Action, and Source Views
In the WebLogic Workshop IDE, you can switch between the Flow View,
Action View, and Source View to create, modify, and view page flow
components. Let's start with a simple page flow to understand the basic
icons you will encounter in the Flow View, and to find out how the Flow View
relates to methods and object in the Source View. In the example, navigation
control is forwarded from one JSP to another. You can find this example in
WebLogic Workshop at:
Here is the Flow View diagram that we created for this page flow in
WebLogic Workshop:
All page flow controller classes have a begin action method to define
what happens each time this page flow is first navigated to. For this page
flow, page_A.jsp is the first page that the
user will see when the page flow's URL is accessed. The begin action is
shown with a blue and green circular icon:
All other actions are represented by a blue circular icon in the Flow
View:
Each JSP file that resides in a page flow's directory is shown on the
Flow View, and is represented by a rectangular icon with a folded
upper-right corner:
An arrow from a JSP page icon to an action icon indicates that the action
can be invoked from the JSP page. For example, if there is a link on the JSP
that calls the action method, this is depicted in Flow View by the following
arrow.
An arrow from an action to a JSP page indicates that the execution of the
action will load the target JSP page into the browser. For example:
The name of each action and JSP page is shown below the icon. The name on
the arrow next to the action's circular icon corresponds to the logical name
of the Forward object that is returned by the action method. The
Forward object's role will be clearer when we look at the source code below.
In the WebLogic Workshop IDE, use the tabs at the bottom of the main
window to switch between the graphical views and source view. When a page
flow is open, its graphical representation is displayed in the Flow View
window. You can switch to the page flow's graphical Action View or to its
code-level Source View:
The Action View allows you to focus on a smaller portion of the page
flow, for instance to examine a particular action and its form bean. The
Source View is where you can customize the generated code and add business
logic, or call controls that implement business logic.
Let's turn to a few examples that demonstrate some of the key features of
navigational control and data processing.
Navigation: a Simple Example
As shown in the Flow View diagram, the page flow class defines an action
method named toPageB. This action can be
invoked by a link on the JSP page page_A.jsp.
...
action="toPageB">Link to page_B.jsp
A special JSP tag library named
netui-tags-html.tld is referenced. WebLogic Workshop provides this
tag library and several others to help you develop dynamic web applications.
The tag used here is
simply invoking an action (toPageB) with a
hyperlink. (For more information about the page flow tag library, see
Designing User
Interfaces in JSPs.)
In the controller file
SimpleNavigationController.jpf, the toPageB
action method is defined as follows:
When the link on page_A.jsp is clicked,
the page flow runtime detects the action and runs the
toPageB action method. This action method is
coded to return a Forward object which passes the parameter
"success". (Notice that this name "success"
matches the name on the corresponding action arrow in Flow View.)
Look at the two @jpf annotations that appear on the lines above this
action method. These annotations are enclosed in Javadoc comments. The
@jpf:action tag indicates that the
toPageB method is an action method. The
@jpf:forward tag describes the behavior of
that method.
Putting it all together, a Forward object is returned by an action
method. The Forward object passes the string "success", indicating that it
should behave according to the directions encoded in the annotation
@jpf:forward name="success". That
annotation's path attribute has the value "page_B.jsp",
which causes the page flow controller to load page_B.jsp into the browser.
The following diagram summarizes the flow in the example:
To change the navigation target of this action method, simply change the
value of the path attribute. For example, if you want this action method to
navigate to page_C.jsp, you would make the following change to the
controller file (no change to the JSP page is necessary).
/**
* @jpf:action
* @jpf:forward name="success" path="page_C.jsp"
*/
public Forward toPageB()
{
return new Forward( "success" );
}
As you will see in later sections, the WebLogic Workshop IDE generates
this code for you when you create a new page flow or JSP file from the
graphical view. This code generation and subsequent validation of your
changes saves you considerable time.
Submitting Data: A Simple Example
Suppose you want to your web application to collect data from users and
then process that data in some way. The following example demonstrates how
to set up a data submission process using page flows. The sample code
referred to in this example can be found at:
Submitting data is a two step process: (1) the data submitted from a JSP
page is loaded into a Form Bean instance and (2) the Form Bean instance is
passed to an action method for processing.
Form Beans are simple Java classes with fields and setter and getter
methods for accessing those fields. Form Beans classes are contained within
the controller file. In most cases, Form Beans are designed to accept data
submitted from JSP forms. For example, if a JSP page has input elements for
name, eye_color, and height, then the Form Bean will have corresponding
fields for name, eye_color, and height. The following example Form Bean can
be found in the controller file
SimpleSubmitController.jpf. It contains one field,
name, and setter and getter methods for that
field.
SimpleSubmitController.jpf
public class SimpleSubmitController extends PageFlowController
{
...
public static class SubmitNameForm extends FormData
{
private String name;
public void setName(String name)
{
this.name = name;
}
public String getName()
{
return this.name;
}
}
}
The input elements on the JSP page are said to be "data bound" to the
fields in the Form Bean. Data binding allows the the data submitted from the
JSP page to be loaded into the Form Bean instance. For example, the input
element on index.jsp contains a data binding expression that refers to the
name field of the Form Bean: {actionForm.name}.
The expression "actionForm" refers to the
Form Bean SubmitNameForm, the property ".name"
refers to the name field of the Form Bean. For detailed information about
data binding see
Using Data
Binding in Page Flows.
index.jsp
Name:
....
Finally the Form Bean instance (carrying the submitted data) is passed to
the action method for processing.
/**
* @jpf:action
* @jpf:forward name="success" path="showName.jsp"
*/
protected Forward SubmitName(SubmitNameForm form)
{
//
// The data is processed here
//
return new Forward("success");
}
The submitted data can be accessed by calling the getter methods on the
Form Bean.
/**
* @jpf:action
* @jpf:forward name="success" path="showName.jsp"
*/
protected Forward SubmitName(SubmitNameForm form)
{
if( form.getName() != null )
// do something here
else
// do something else here
return new Forward("success");
}
By default the Form Bean instance that is passed to the action method
exists only as long as the HTTP request. This is called a "request-scoped
Form Bean". When the HTTP request is destroyed, the Form Bean instance,
along with the user submitted data, is destroyed. As an alternative, you can
use a Page Flow-scoped Form Bean, which has a longer life cycle. For details
see Form
Bean Scopings.
Displaying Data: A Simple Example
Suppose that once you have collected data, you want to display it back to
the user. The following example shows how to use data binding to display
data to the user. The sample code referred to can be found at:
Displaying data using data binding requires that (1) the data is located
somewhere where it can accessed by the JSP page and (2) the JSP page uses a
data binding expression to retrieve the data from that location.
Notice the syntax of data binding expression on the JSP page. (1) It is
framed by curley braces, (2) it begins with a data binding context, in this
case the request context, and (3) the context is followed by an attribute,
in this case "name".
In the following example, an action method places data on the
name attribute of the
request object.
After the data has been located on the name
attribute of the request object, it is
displayed on a JSP page using a data binding expression.
showName.jsp
Here is the data you submitted:
Note that the request object has a relatively short life-cycle. When the
user makes a new request, by navigating to a new JSP page or invoking
another action method, the current request object is destroyed along with
the data it contains. If your application requires the data to be more
persistent, then you could use a different data binding context, for example
the session object or a Page Flow-scoped
Form Bean, which both have longer life-cycles. For detailed information
about the different data binding contexts available, see
Using Data
Binding in Page Flows.
Advantages of Using Page Flows
This topic outlines the advantages of using page flows in your web
applications. You may be familiar already with the Struts framework, which
is a part of the
Jakarta
Project by the Apache Software Foundation™. Struts is an open-source
framework for building Web applications based on the model-view-controller
(MVC) design paradigm. WebLogic Workshop page flows extend the Struts
framework to provide a simplified development model with numerous additional
features:
Ease of use
Typically, native Struts development requires management and
synchronization of multiple files for each Action, form bean, and the Struts
configuration file. Even in the presence of tools that help edit these
files, developers are still exposed to all the underlying plumbing, objects,
and configuration details. Page flows provide a dramatically simpler,
single-file programming model that allows you to focus on the code you care
about, see a visual representation of the overall application flow, and
easily navigate between pages, actions, and form beans. Page flows also
provide a number of wizards to automate common tasks and visualize tag
libraries. Furthermore, page flows provide key programming model benefits
like thread safety. As a developer, this means that you can be insulated
from some of the complexities that are pervasive in other web development
models today like Struts and servlets. The result is that page flows enable
you to become immediately productive in building sophisticated web
applications, without the learning curve typically associated with Struts.
Nested page flows
Struts provides a useful framework for smaller applications, but has
trouble scaling to larger applications. Every page and action is referenced
from a single configuration file, and the manageability of applications and
projects quickly degrades as the size of the application increases. But with
the nesting feature of page flows, you can easily create smaller nested
applications that are linked together, helping to enforce a modular design
paradigm and supporting larger team development projects. Importantly,
nested page flows automatically manage session state as a user moves between
them, ensuring that the minimum possible level of system resources is used.
State management
Page flows make state management easy. You can put data in session state
simply by using a variable in your JPF controller class, unlike with Struts
action classes. Or you can easily pass data (as Java beans) to individual
pages. Data stored in the session state is automatically freed as a user
leaves the page flow for efficient use of session data.
Rich Data binding features
The WebLogic Workshop data binding tags and wizards make it easy to
create rich, dynamic pages within a page flow. These features enable binding
of user interface (UI) components to numerous data contexts (not just
limited to form beans) and the data may come from any source: a database, a
web service, an EJB, a custom application, and so on. In the IDE, you can
drag-and-drop the data binding tags to your JSP page and bind to data,
including complex types such as method invocations, repeating data, and
grids. For more information, see
Using Data
Binding in Page Flows and
Presenting Complex
Data Sets in JSPs.
Service-oriented design with Java controls
Page flows have full support for Java controls, a simple programming
model abstraction for accessing enterprise resources and packaging business
logic. Java controls give developers access to the powerful features of the
J2EE platform (security, transactions, asynchrony) in a simple, graphical
environment with methods, events and properties, and enable developers to
build Web applications conforming to best practices for service-oriented
architecture. For more information, see
Tutorial: Java Control.
Integration with Portal
Have a page flow? You can easily also have a portlet! Page flow
applications can be instantly turned into portlets via a wizard in WebLogic
Workshop. For more information, see
How Do I: Create a Portlet? and
How Do I: Add Portal Functionality to an Existing Page Flow Application?
Strong data typing
Struts treats all data as a String, making it difficult to work with rich
form data. Page Flows, on the other hand, allow developers much easier
access to strongly-typed data, making it a lot easier to work with form
information.
Powerful exception handling
You can handle exceptions by pointing to local actions in your page
flows, Page Flows, and handle not-logged-in errors globally across a set of
page flows. This makes it much easier to manage errors and centralized login
processes for your entire application versus managing a cloud of exception
handler classes in Struts. WebLogic Workshop provides a number of exception
types that represent common exception scenarios for page flow applications,
such as ActionNotFoundException,
LoginExpiredException, and
UnfulfilledRolesException.
For more information, see
Handling
Exceptions in Page Flows.
Iterative development experience
With the WebLogic Workshop IDE and page flows, you do not need to go
through the tedious development cycle of edit, build, deploy, and test.
Simply make a change in the IDE and click the Run button. The WebLogic
Workshop model for automated deployment and integrated testing displays the
results of your code change immediately. Plus, more errors are caught
up-front through the WebLogic Workshop page flow compiler, instead of
discovering the errors at runtime through exceptions or unintended behavior.
Built on the open-source Struts framework
While page flows provide a number of compelling advantages relative to
Struts, keep in mind that page flows are based on Struts. This means that
page flows can interoperate with existing Struts applications. You can
always use the Struts Merge feature of page flows to obtain full access to
underlying Struts artifacts and their configuration details. And page flows
can interoperate with existing Struts applications, with both residing in
the same web project. Also, with the page flow portability kit, you can run
a page flow application on Apache Tomcat™ and any J2EE-compliant Servlet/JSP
2.3 container.
Share And Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.
Keywords:
Developing Web Applications, WEBLOGIC, WebLogic, WebLogic tutorials, WebLogic tutorial pdf, history of WebLogic, How To Deploy An Application Using WebLogic , learn WebLogic
