JSF Handler part

An EGL JSF Handler part controls a user's runtime interaction with a web page and can do any of these tasks:

The JSF handler itself includes variables and the following kinds of logic:

The variables in the JSF handler are accessed in two ways:

Keep the JSF Handler part simple. Although the part might include lightweight data validations such as range checks, invoke other programs to perform complex business logic. For example, perform database access in a called program only.

Output associated with a JSF handler

When you save a JSF handler, EGL places a JSP file in the WebContent\WEB-INF folder, but only under the following conditions:
  • You assigned a value to the JSF handler view property, which specifies a JSP file name
  • The WebContent\WEB-INF folder does not contain a JSP file of the specified name

When generating a JSF handler, EGL never overwrites a JSP file.

If a Workbench preference is set to automatic build on save, JSF handler generation occurs whenever you save the JSF handler. In any case, when you generate a JSF handler, the output is composed of the following objects:
  • The page bean is a Java™ class that contains data and that provides initialization, data validation, and event-handling services for the web page. In the documentation that refers to runtime events, the phrase JSF handler is sometimes used to refer to the page bean.
  • A <managed-bean> element is placed in the JSF configuration file in your project to identify the page bean at run time.
  • A <navigation-rule> element is created in the JSF application configuration file to associate a JSF outcome (the name of the JSF handler) with the JSP file to be invoked. See "Page navigation."
  • A JSP file is generated when you save the JSF handler.

All data tables and records that are used by the JSF handler are also generated.

Validation

If the JSP-based JSF tags perform data conversion, validation, or event handling, the JSF runtime does the necessary processing as soon as the user submits the web page. The following EGL-based validations occur as if they were JSF-based validations:
  • Elementary edits (such as minimum input length) for individual input fields.
  • Type-based edits (character, numeric) for individual fields.
  • DataTable edits (range, match valid, and match invalid) for individual input fields; see "DataTable part."
  • The onValueChange function for an individual input field.
If the EGL runtime finds an error in the previous validations, the JSF runtime code re-displays the same web page with embedded error messages. If all the previous validations succeed, the EGL validator functions run, as follows:
  1. All the validator functions run for the individual input fields, even if some of those validations fail
  2. If all those validator functions succeeded, the validator function runs for the JSF handler as a whole

If a validator function finds an error, the function can forward control to another web page, but the default behavior is to re-display the same web page.

The validationOrder field-level property defines the order in which the field-specific EGL validator functions are invoked. The property has no effect on the order of onValueChange functions that run earlier.

If no validationOrder properties are specified, the default is the order of fields defined in the JSF handler, from top to bottom. If validationOrder is defined for some but not all of the fields in a JSF handler, validation of all fields with the validationOrder property occurs first, in the specified order. Then, validation of fields without the validationOrder property occurs in the order of fields in the JSF handler, from top to bottom.

JSF scopes

This section includes material from IBM® Rational® Business Developer with EGL (http://www.mc-store.com/5087.html).

The JSF runtime assigns the EGL JSF handler to one of three scopes, each of which defines the lifetime of a managed bean. The scopes correspond to the three possible values of the Scope property: request, session, and application. The three scopes are available to you, as well, allowing for temporary storage as you transfer data from one function to another in the same or a different EGL JSF handler:

  • Request scope is available from the time that the JSF runtime receives a request from the user until your code responds to that user. An EGL JSF handler in request scope might provide the status of a specific order in response to a user request. You can store data in request scope regardless of the Scope property value.
  • Session scope is available from the time that the JSF runtime receives data from the user and lasts through multiple user-code interactions until the server session is made invalid. The server session is made invalid in several ways: for example, by a session timeout or because the EGL JSF handler is restarted — re-initialized — in the web application server. A handler in session scope might hold an order number required for a series of interactions. You can store data in session scope when the Scope property value is session or application.
  • Application scope is a multiple-user scope and is available from the time a web application starts for any user and lasts until the application is terminated. An EGL JSF handler in application scope might hold the next available order number. You can store data in application scope when the Scope property value is application.
Several functions in the library j2eeLib let you store, retrieve, and clear data from one scope or another. For example, the following functions are available for interacting with the data stored in request scope:
  • j2eeLib.setRequestAttr()
  • j2eeLib.getRequestAttr()
  • j2eeLib.clearRequestAttr()

The names of the equivalent functions for session or application scope are similar; for example, j2eeLib.setSessionAttr().


Feedback