# Best Practices for Page Flow Applications

This topic presents best practices for creating page flow web applications, describing tip and tricks, and ways to avoid problems.

- Location of Business Logic
- Form Validation
- Template JSPs, Contents JSPs, and Relative versus Absolute URLs
- Security
- Avoid Creating a Page Flow with the Same Name as Another Entity
- Using Read-Only Actions, Where Appropriate
- Working with Large Web Applications

## Location of Business Logic

Business logic includes both the navigation control for page flows and the implementation of other business processes such as data handling. In general it is preferable to put the navigation logic in the page flow's controller (JPF) file. Data handling and other business process implementations should in principle be implemented using the other WebLogic workshop components such as built-in and custom controls, web services, and regular Java classes. These components are called by the page flow's controller file, and the results of this interaction is returned to a JSP. For more information, see Working with Java Controls and Building Web Services.

## Form Validation

When you validate user input through a form on a JSP, there are two ways to accomplish this:

- Client-side validation. For instance, you add JavaScript to the onBlur or onChange method of a <netui:textBox> or to the onClick method of the <netui:button> tag. When an error is found, it can be reported to the user in a dialog.
- Server-side validation using the validate method or the Struts ValidatorPlugIn. When a form is submitted, the data is checked on the server. When an error is found, an error message can appear somewhere on the form page itself, for instance next to the affected field, or the user might be sent to a new page displaying the error messages, depending on the implementation details of the server-side validation.

Both approaches have their own strengths and weaknesses. A drawback of client-side validation is that the JavaScript is embedded directly in the JSP instead of stored separately from the user interface in a JPF or Java file. Another problem is that you have little control over the browser side. The user might actively attempt to bypass client-side controls, or use a (possibly outdated) browser with features that conflict with your validation code. In contrast, server-side validation is fully under your control.

A drawback of the server-side validation is that all the form data needs to be routed to the server and errors need to be passed back. If this is a concern, you might consider using both client-side and server-side validation. Use client-side script to catch obvious errors, and use server-side logic to do a thorough validation.

For more information about both approaches, see Validating User Input.

## Template JSPs, Contents JSPs, and Relative versus Absolute URLs

In a Web project, a template page is a JSP that defines the overall look and feel of a set of pages. It does this by providing an overall layout structure, style, and design of the page, and defines placeholders for content. Note that when you use relative URIs inside a template with the <netui:base/> tag, the URI is interpreted as relative to the content JSP page that uses the template, and not as relative to the location of the template. If you use a template to ensure that a certain element is included on every web page, for instance a gif containing the company logo, you should use an absolute URL.

Recommendations for using templates:

- Templates need to use absolute URLs if the template is used to include a standard element.

- You should be careful about using JSP tags from the netui-tags-* libraries in templates. These tags may contain "actions," but those actions are relative to the content page's page flow. This means that each page flow that uses a template would have to implement the action, or the action must be defined in the GlobalApp.

- For some netui* tags where you must use them in a template, using the url= attribute instead of the action= attribute is best. For example, the <netui:anchor> tag should use the url attribute.

- If the template contains the <html> or <netui:html/> tag, you probably should also include the <netui:base/> tag. This ensures that the relative URL on the content pages are based correctly.

Recommendations for content JSPs:

- Use relative URLs when possible.

- When you are not able to use relative URLs:

  - Use request.getContextPath() to prefix absolute URLs when addressing items within the same web application.

  - Use http://hostname/appname/ to prefix absolute URLs when addressing items outside of the web application.

## Security

For most web applications, security is a vital issue to protect the confidentiality and integrity of data. When designing a secure web application, you should considering the following issues:

- WebLogic Workshop comes with a security model that enables you to use secure transport protocols, and allows you to implement overall access to the web application, and fine-grained security to components of the web application, on the basis of a user's security role. For more information, see Security.
- When adding data to a data binding context, consider the scope of the data use. It is a good design practice to limit data availability to those action methods, page flows, and JSPs that require this data. This will help safequard unintended access or even modification of the data. For instance, if you only need data for a particular JSP, consider using request instead of pageFlow. Also notice that passing data as attributes on a URL is especially unsafe, as it allows for easy modification and can even enable undesired access to other data by a malintended user. For more information, see Lifetime and Scability of Data Binding Contexts.
- Consider using further restrictions to limit access. A frequently used restriction is the notion of timeouts, where a user session is disabled when a certain amount of idle time is passed. You can for instance use client-side JavaScript to enable timeouts - consider adding this to the template page(s) you use to build your JSPs - and/or you can implement server-side timeouts, for instance by restricting the time before a session times out. For more information on session timeouts, see the session data binding section in Using Data Binding in Page Flows.

## Avoid Creating a Page Flow with the Same Name as Another Entity

The Page Flow Wizard and Database Control Wizard allow you to create a new directory with the same name as an existing Java-based file. Using identical names results in packaging conflicts, which cause parse errors in .jws, .jcs, .jcx, and .java files. Avoid naming a directory and a peer Java-based file the same name. If you do this inadvertently, simply rename one of the entities.

## Using Read-Only Actions, Where Appropriate

You may be able to improve the performance of your page flow webapps in WebLogic cluster environments. The @jpf:action annotation provides an optional attribute, read-only={" true | false " }. The default is read-only="false". You can designate read-only="true" to indicate your intention that this action will not update any member data in the page flow. In a cluster environment, this designation causes WebLogic Workshop to skip any attempted failover of the page flow after the action is run. This makes it unnecessary for WebLogic Workshop to communicate portions of this page flow's state data across the nodes in the cluster that pertain to the read-only actions, which may improve performance. Note however that if the action marked as "read-only" calls, or is called by, other actions that are read/write, WebLogic Workshop must replicate the state of the actions across nodes in the cluster. Therefore you should only use the read-only="true" option if you know that the action and any directly related actions will not update member data.

## Working with Large Web Applications

When working with large web applications, especially those that contain a large number of JSP pages, it is recommended that you build the web app by clicking the Run button (= Ctrl+F5), rather than the Build button (= F7). The Build button will cause a full re-compile, including the JSP pages in your app, which may take a long time if your app is large. The Run button, on the other hand, uses a compiler cache for the JSP pages.

Related Topics

Getting Started with Page Flows

Page Flow and JSP Reference