1. Web JSF Overview – Dynamic Content Web Pages – for EGL/JSF Developers
This unit introduces you to the technical concepts of dynamic content web pages, the JSF lifecycle on the web, and the EGL JSFHandler properties.

2. Topic Objectives Sub-topics for this section: Internet “101”
Lifecycle
URL/URI
Browser technology
.CSS
Dynamic Content Web Pages – terms and concepts
JSPs and Servlets
JSF
Terms and concepts
EGL and JSF
Faces-config.xml
RBD Tooling
Template pages
Customizing the palette

3. Dynamic Data Content Web Technology
Using EGL and JSF you create web pages that render data dynamically
Translation – the data ultimately viewed by your users in the browser will be:
Dynamically read from a database (using EGL data access statement)
Processed by EGL business logic – which creates data bound to JSF components
Which are processed by JSP/Servlet technology and ultimately
Displayed in HTML pages.
See Notes for additional details
Browser
Page
HTTP Request
Data Transfer
HTML +CSS + data DB
 Notes: If you’ve done CICS or IMS DC (online) programming this will sound familiar to you. However
a wrinkle thrown into this paradigm is that the software responsible for rendering the data
dynamically must build the entire HTML stream, before publishing the page to the browser.
This includes:
All HTML tags and controls, including:
Fields and labels
Selection boxes
HTML Tables
Hyper-links
Etc.
The dynamically-built data content
Static text and images
JavaScript – the Java-like language, used to render page elements dynamically (responding to
browser events on the client/PC, setting cursor focus in a field, etc.)
The components necessary to facilitate complex work like this include the following, which are explained
further:
Browser
J2EE Servlets and JSPs
JSF Life cycle
JSFHandlers and your EGL Business Logic
EGL and JSF Page Data – Referencing EGL Variables
EGL and JSF Page Data – Referencing EGL Functions
Application
Server
EGL Application
Process data
Access database
Call legacy systems
System I
System z

4. J2EE Servlets and JSPs – “Geek Speak”
Browser
Servlets are modules of Java code that run inside a “Servlet container”*** (Notes) running in an application server (like WebSphere or Tomcat).
Servlets are the executable form of .JSP pages. And they are used to provide back-end (server/side) support for dynamic content applications, by:
Processing and/or storing data submitted by an HTML form
Dynamically rendering the HTML (tags + data) for a page
Java Server Pages (JSPs) are also modules of Java source code that get compiled and run on an application server.
JSPs are used to simplify the development of dynamic content web pages that interact with application processes (EGL) and databases (Java Servlet code is very complex to write. JSPs are much easier)
JSP pages exist in their source form, in your application.
When they are executed, the system compiles them to J2EE Servlets on-the-fly.
Request
(URI)
Response
(HTML + data)
WebSphere
Servlet Container
Servlet
Java (managed) Bean
Your EGL JSFHandler
 Notes: 1. There is a dedicated JSF (Faces) Servlet-listener program that is responsible for handling traffic flow from outside requests (URLs).
This Servlet gets control from WebSphere initially, opens up faces-config.xml to look for your program, loads your program and passes control and parameter data to it.
2. A Servlet container is a specialized web server that supports Servlet execution. It interacts with the servlets, and is responsible for managing the following:
Lifecycle (create new instance, garbage collect, etc.)
UFL mapping
Access rights

5. Java Server Faces
Java Server Faces (JSF) is a Java-framework (pre-constructed code you use or
call…versus having to write from scratch) for building Web applications using EGL
generated to Java.
JSF provides you with the following features:
Dynamic Content rendering – generating browser-ready HTML tags and data
This complex, time-consuming and deep J2EE/Java development process becomes “declarative programming” using RBD and EGL
Page navigation specification
Standard user interface components like input fields, buttons, and links
User input validation
Easy error handling
Integration with EGL
Binding components to EGL Page Data values
Binding Actions to EGL functions
Binding JSF properties to EGL Page Data values
Integration with Page Designer and other tools, such as:
Template pages and Site Designer
Event handling
Integration with client-side processing, including:
JavaScript
AJAX technology
In short, JSF provides the common plumbing for the U.I. elements of your Web application (just
as EGL provides the plumbing for the business and data access logic) allowing you to
concentrate on your business requirements (instead of worrying about things like how to
create a link from one page to another).
 Notes:

6. JSF LifeCycle Notes: Events and Discussion
The user enters a URL into the browser Address area – ex. and clicks Go (or presses Enter). This formats an HTTP Get Request, creates a request variable named: cid with a value of 3, and launches your page via the following steps:
– is the logical address of an internet resource. This logical address is translated to a physical I/P address in the form of nnn.nnn.nnn.nnn – which is the location of some known network address on the Internet backbone. This network address ultimately points to the root directory (think the WebContent folder) of your application. Note that /faces/ then specifies a reserved directory for Faces/JSP pages that include EGL. A special Servlet exists that is described below
The internet locates the application server using the I/P address and invokes the faces Servlet. Why a Servlet and not a .JSP? Because by J2EE convention, .JSP pages (which actually exist only in source format) get compiled to J2EE Servlets “on the fly” during execution. Note that WebSphere Application Server will also create for this user a “Session” object (not shown). Session objects are areas of storage your program can utilize to maintain the state of your conversation or transaction with a particular user. The EGL QuickStart course described Session objects in detail.
The faces Servlet looks in the faces-config file for the “managed bean” named: updatecust – and passes control to it. This is after it has processed all the raw HTML values passed (in this case the only value to be processed is the input parameter (cid=3), but if say, you submit a form there could be many values). “Processing” values happens in the code we refer to as the JSF Framework. Java APIs that invoked based on your Page Designer work.
The JSF Framework calls your EGL “Managed Bean” (essentially your JSFHandler) for the .JSP page
The EGL “Managed Bean” for updatecust.jsp is invoked. A “Managed Bean” is a standard Java/J2EE class that contains:
The EGL statements in your JSFHandler
EGL Framework code, generated into the manage bean, to handle aspects of the “presentation” and “persistence” logic (casting (redefining) values, creating the EGL records and fields you reference in your code from the HTTP stream and WAS server objects, etc.
If this is the very first time the Managed Bean has been invoked for this user’s session, Your JSFHandler can call or invoke any number back-end services, including data access functions in libraries, EGL, RPG, COBOL programs or C.I.C.S. transactions, etc. In this case, the customer_id is used to look-up the record for customer#3.
The database returns (or not) the record for customer #3 to your JSFHandler
The JSFHandler will process the data in EGL and upon exit the JSF Framework receives all Page Data values bound to page controls, and processes these values, populating internal Java artifacts. This dynamically creates the complete .JSP page
The .JSP page is compiled to a Servlet (see above) and the Servlet is used to dynamically create a standard HTML data stream (HTML tags and data values)
The HTML is sent back to the user’s browser via the I/P address attached to the incoming request. The browser running in the user’s PC interprets the HTML and renders the controls and data (and runs any dynamic JavaScript commands).
For you uber-geeks (“serious techies”) Appendix 1 contains information on the JSF Run-Time. Details on the salient EGL and JSF portions of the above continue (unabated).

7. faces-config.xml (Your Project’s Web Page “Table-of-Contents”)
 faces-config.xml – a file inside the \WEB-INF\ folder (which is inside \WebContent\)
faces-config.xml is the Java Server Faces configuration file. This file lists Java resources (your compiled JSFHandlers) and the .JSP page navigation rules (links, etc.). Here’s an example…
Why do I care about faces-config?
Well, most of the time you won’t, as the entries to faces-config are automatically made by the RAD tooling. But there will be two instances where you might want to modify what’s there:
From the above you can see that the “managed-bean-scope” (recall that the managed bean is in essence your JSFHandler). So the default scope of your JSFHandler is session – which means that the same executable – and all the Global variable values – are retained in memory. This is probably right for 90% of your pages. But what if a page needs to re-invoke itself, and re-load data from SQL tables?
In this case, you’d want to change the <managed-bean-scope> to: request
You may have noticed that when your pages forward to other pages (not via a link but using an EGL forward statement), the browser’s URL did not update? This is because of the HTML generated for the request. You can show the URL by changing a value in the <navigation-case> section of faces-config for the page that is being forwarded to. Note that you add <redirect/> as shown here.
** DISCLAIMER ** Note also that the JSF redirect element causes the JSP container to terminate the current request and send an HTTP redirect to the client. The redirect response tells the client which URL to use for the next page and allows the browser to update its address field as well. In English, this means two server-browser requests, and is not a “Best Practice” when it comes to page performance

8. JSFHandlers and EGL Business Logic
Your JSFHandler controls the user’s run-time interaction with a web-page. It is responsible for retrieving and processing data bound to variables displayed on the page, and for handling user events that fire server-side logic (i.e. the user clicks a submit-button or dataTable row, or makes a selection from a combo-box that invokes a custom function in a JSFHandler.)
JSFHandlers adhere
to the standard EGL
coding model.
They have properties
Global variables
(Page Data variables)
And functions
 Search Help
on the topic:
JSF Handler Part
 Technical notes: Please do check out the help on JSF Handler Part

9. The JSFHandler EGL Properties
You learned in the EGL Language tutorial about EGL properties for DataItems, Records and
primitive variables.
You may also have noticed a number of interesting looking (okay – interesting may be a poor choice of words here) set of EGL properties that are associated with JSFHandlers.
There are about a dozen JSFHandler properties (properties that affect the code generation for the entire JSFHandler, or managed-bean).
The majority of the time you will not want to modify the JSFHandler property defaults (exceptions being: 1. cancelOnPageTransition, 2. msgResource (for internationalization)
Properties of a JSFHandler 
Other JSFHandler properties
you may enable
If you do a product help search on: JSFhandler part properties, you will see an in-depth explanation of all the properties.
The properties you might wish to become familiar with (because you may want to over-ride their defaults) are as follows:
allowUnqualifiedItemReferences – which allows you to refer to fields within record structures without the high-level variable or group names. Note that allowing unqualified reference is not a “best practice” – as the code is more self-documenting when qualifying variable names completely
handleHardIOErrors – The variable controls whether a program continues to run after a hard error has occurred on an I/O operation in a try block. The default value for the property is yes (continue to run)
msgResource = "fileName" – Identifies a Java™ resource bundle or properties file that is used in error-message presentation. The Java runtime searches for the file, which must be in a directory listed in the Java classpath. Note that you may set a global (server-wide) variable for messages as well as at the individual JSFHandler level by adding a Variable to the web.xml (deployment descriptor) file. This option is useful for: Localization requirements, and for over-riding the default JSF and EGL error messages. Note that the TechSamples application contains a detailed “How To” example of using a custom msgResources file to implement both: Localization and over-riding the default error messages requirements.
scope = session/request - Specifies when the JSFHandler (the page bean) is removed from memory in the Web application server: See previous discussion of this under faces-config.xml
validationBypassFunctions = ["functionNames"] – Identifies one or more JSFHandler functions that are associated with a button control in the page to skip Input field and Page level validations for.
validatorFunction = "functionName" - Identifies the JSFHandler validator function, which is invoked after all the field validators are invoked.

10. Data Access Best Practices
Throughout the course we’ve used onConstruction as our primary initial page load function. This however may or may not be the best practice for pages that require data access on load.
It is best to put any long running initial data access queries in the onPreRender function.
Doing so will give you better control over your code and allow you to debug easier. This is because preRender runs each time the page loads no matter what.
Historically we’ve used onConstruction for every page that requires on load functionality. Ever since RBD v7.1, however, it has become optimal to use preRender when there is data access involved.

11. Three Important JSFHandler Functions
There are three reserved functions in all JSFHandlers:
onConstruction
For session scope pages** (see notes) This function is executed the first time the page (managed bean) is loaded from the server. It is not executed when a form is submitted.
For request scope pages** (see notes) This function is also executed upon every form submit (even if there is a validation error)
onPreRender
For both session and request scope pages, this function is executed after onConstruction() – if specified - and then upon every form submit (even if there is a validation error) BEFORE the page is rendered. It is typically used to do things such as refresh JSFHandler variables.
onPostRender
For both session and request scope pages this function is executed after onConstruction(), after onPreRender() – if specified – and then upon every form submit (even if there is a validation error) AFTER the page is Rendered. It is typically used to do things such as save variable values to session, etc.
onConstruction(), preRender(), postRender():
Are only executed if their associated JSFHandler properties specify a function
onPrerenderFunction = onPreRender, onConstructionFunction = onConstruction…
Have access to all the functions and variables in the page
Can access parameters passed from a forward statement or from the query strings within a URL. The parameters persist as request data.
If the functions are defined without any parameters, any arguments passed to the function by a forward statement or a link are ignored, and the parameters assume their default values
int = 0, string = “” (empty string), date = current date, etc.
Your JSF pages can be defined as either session or request in scope. We will cover this in-depth later in the course.

12. EGL and JSF Page Data – Referencing EGL Variables
 In order to make your EGL variables available to JSP pages, they must be defined as public variables (not defined as private).
 Notes:

13. EGL and JSF Page Data – Referencing EGL Functions
In order to make your EGL functions available to JSP pages, they must not have parameters in the function signature, and can not be designated as private functions.*** Notes
Notes: Also – onConstruction() cannot be invoked from a Web Page. onPreRender() and onPostRender() if defined will always be invoked – once when your page is initially loaded, and upon each form Submit

14. EGL and JSF – Value Bindings - Refactoring? (not)
As soon as you drag and drop or bind an EGL variable to its JSF component, the RBD tooling makes a JSF source statement entry and hard-wires a generated name for the value.
At this point in time you can not simply change either the name or even the case of your EGL JSFHandler variable - or any part of it (i.e. record name, field name, etc.) – as your change will not be refactored in the JSF source, and a run-time error will occur, as Java will be looking for
<originalVarName> (case and all) ***Notes
If you need to change EGL JSFHandler variable names, you can do so, if you re-drag the field from Page Data on top of the JSF component – and re-bind its value.
The above also holds true for JSF Submit Buttons (and the EGL functions that they invoke) – that is, once you drag the EGL functions onto a page and bind them to JSF Submit Buttons, if you change the function name, re-drag/bind.
Time 1. Create a JSF component
Time 2. Bind the component’s value
to an EGL JSFHandler variable
Time 3. Modify the spelling or case
of the EGL variable name
Note that EGL will not care about you changing Variable name case – as it is a Case-insensitive language (up to the point where it interfaces with Java – hence the information presented on this slide)
Time 4. Run the page on the server
(will receive Java Run-time error)

15. EGL and JSF – Value Bindings – The Big Picture
(In Design Mode)
Customer record dragged onto a page, which creates the form  – and individual controls to hold the record’s variable values – including the State variable
You can see this in source mode 
updatecustomer2 = page name
customer = record variable name
State = field-within-record variable name
JSF Design Mode view
JSF Source Mode view 
JSFHandler Record Variable
EGL Record Declaration (Field name)

16.  JSF Properties
During page design, you may customize the JSF properties for the data and other elements of your page design.
This is done by selecting a field and accessing the Properties tab.
Properties has a default and an “All Attributes” view
Quick Workshop
Select any component on any page.
From Properties – switch back and forth from normal Properties to All Properties
Properties
All Attributes view

17.  Selecting JSF Components in Page Designer
There are four different ways of selecting controls in Page Designer
 Mouse-select
Left-click the control in the Content Area
 Keyboard select
 (From any mouse-focus point in Page Designer) Move up/down and right/left using your keyboard
If you start from a component inside another component (example: a control within a dataTable) – the up arrow will select descendant/parent container components
Note that you can combine the up/down/right/left arrow keys
i.e. Use right arrow to navigate, left arrow to select
 Properties menu select
Allows you to navigate to all JSF and HTML Tags on a page
For all complex components (container controls) you can access sub-properties not available from any other selection mode
Outline view

18. JSF and HTML and JSF B R I C K W A L
Essentially, any JSF (Enhanced Faces) component can integrate and works with any other JSF component.
For examples
You can drop a JSF Link on top of a JSF output field, or drop a JSF comboBox inside of a JSF dataTable, etc.
And any HTML Tag integrates and works with any other HTML Tag
You can put an HTML Link on an HTML image, etc.
But (except for the HTML Table Tag and JSF Panel-Group Box/JSP) you cannot mix JSF and HTML.
For example
You can NOT drop an HTML Link on a JSF output control.
You can NOT drop a JSF Link on an HTML image
Etc. B R I C K W A L
Notes:

19.  Adding the JSF Component Tree Facets
You will want to use a powerful facility in EGL/JSF called the Component Tree. It will allow you to do U.I. dynamic programming without having to learn JavaScript. But this Component Tree feature must be enabled.
 (From Project Explorer) Right-click over EGLWeb and select Properties (it’s the bottom option on the context menu)
(From Project Facets) click:
Add/Remove Project Facets
Check:
 EGL support with JSF Component Interfaces
 Enhanced Faces components
Click Finish
Click OK

20. Testing Your Pages (Removing JSFHandler Beans From App-Server Cache Memory)
 As will be explained in an upcoming unit on Session Management, your EGL JSFHandler files (the java “page beans”) can often be held in persistent memory by your application server (either WebSphere or Tomcat). The App-Servers do this, in order to improve performance and response time.
However, this can wreak havoc - or at least it can be annoying  - during page testing, when you need to see “cause and effect” with your changes
 To flush individual Page Beans (JSFHandlers) from App-Server memory:
From inside the JSFHandler .egl file
Set focus and press Ctrl/G
 To flush all Page Beans from App-Server memory:
From the Servers tab
Right-click and select: Add and Remove Projects
Remove your project, then
Add your project back
EGL
JSFHandler
Cache
Memory
EGL
JSFHandler
EGL
JSFHandler
…serves…
App-Server
Your .JSP pages

21. Best Practices – “MVC-Like” Software Architecture
 By using JSFHandlers as they were meant – for U.I. logic, responding to user-events, managing state and for page navigation – you can architect an 3-tier environment, providing maximum: scalability, flexibility and reuse.
AJAX/JavaScript
 Technical notes:
JSP Pages and JSFHandlers
Each .JSP page will have a one-to-one correspondence with a JSFhandler.egl file of the same name. The .JSP page will be generated to standard Java .JSP file. The JSFhandler.egl file is generated to a Java program (a Java bean class … not an EJB).
EGL Libraries
Each EGL Library file is generated to a Java program. Individual functions coded within the library may be called directly from EGL statements inside JSFHandlers.
The EGL Library file must reside on the same machine (local) as the EGL JSFHandler that calls its functions.
EGL Programs
Each EGL Program file is generated to a: Java program, Java wrapper, or EJB (Session Bean). You pass parameters to an EGL program from any calling source (there is a single point of entry).
The EGL program can be located and called either locally or remotely. It is important to point out that EGL programs can also be generated to iSeries and z/OS environments in COBOL.