The JSF handler itself includes variables and the following kinds of logic:
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.
When generating a JSF handler, EGL never overwrites a JSP file.
All data tables and records that are used by the JSF handler are also generated.
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.
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:
The names of the equivalent functions for session or application scope are similar; for example, j2eeLib.setSessionAttr().