web jsf overview – dynamic content web pages – for egl/jsf developers

®

IBM Software Group

© 2006 IBM Corporation

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.

2Last update: 12/04/2007

Topic ObjectivesTopic Objectives

Sub-topics for this section: Internet “101”

Lifecycle URL/URI Browser technology .CSS

Dynamic Content Web Pages – terms and conceptsDynamic Content Web Pages – terms and concepts JSPs and ServletsJSPs and Servlets JSFJSF

– Terms and conceptsTerms and concepts– LifecycleLifecycle

EGL and JSFEGL and JSF Faces-config.xmlFaces-config.xml

RBD Tooling Template pages Customizing the palette


Dynamic Data Content Web TechnologyDynamic 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

ApplicationApplicationServerServer

EGL ApplicationEGL ApplicationProcess dataProcess data

Access databaseAccess databaseCall legacy systemsCall legacy systems

HTML +CSS + dataHTML +CSS + data

HTTP HTTP RequestRequest

DBDB

BrowserBrowser

PagPagee

PagPagee

Data TransferData Transfer

System ISystem ISystem zSystem z


J2EE Servlets and JSPs – “Geek Speak” J2EE Servlets and JSPs – “Geek Speak”

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.

BrowserBrowser

WebSphere

Servlet Container

Servlet

Java (managed) Bean

Your EGL JSFHandler

Request (URI)

Response(HTML + data)


Java Server FacesJava 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).


JSF LifeCycleJSF LifeCycle


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…


JSFHandlers and EGL Business LogicJSFHandlers 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 adhereto the standard EGLcoding model.

They have properties

Global variables(Page Data variables)

And functions

Search Help

on the topic: JSF Handler Part


The JSFHandler EGL PropertiesThe 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 Properties of a JSFHandler

Other JSFHandler propertiesOther JSFHandler propertiesyou may enableyou may enable


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.


Three Important JSFHandler FunctionsThree Important JSFHandler FunctionsThere 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():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.


EGL and JSF Page Data – Referencing EGL EGL and JSF Page Data – Referencing EGL VariablesVariables

In order to make your EGL variables available to JSP pages, they must be defined as public variables (not defined as privateprivate).


EGL and JSF Page Data – Referencing EGL FunctionsFunctions 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 privateprivate functions.*** Notes


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 valueto an EGL JSFHandler variable

Time 3. Modify the spelling or caseof the EGL variable name

Time 4. Run the page on the server(will receive Java Run-time error)


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

JSFHandler Record Variable

JSF Design Mode view

JSF Source Mode view

EGL Record Declaration (Field name)


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

PropertiesPropertiesAll Attributes viewAll Attributes view


Selecting JSF Components in Page DesignerSelecting 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 keysi.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


JSF and HTML and JSFJSF and HTML and JSF

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. Etc.

BBRRIICCKK

WWAALLLL


Adding the JSF Component Tree FacetsAdding 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 FacetsAdd/Remove Project Facets

Check:Check: EGL support with JSF Component Interfaces Enhanced Faces components

Click Finish

Click OK


Testing Your Pages (Removing JSFHandler Beans From App-Server Cache Memory)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/GSet 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

App-ServerApp-Server

CacheCacheMemoryMemory

……serves…serves…

Your .JSP pagesYour .JSP pages

EGLEGLJSFHandlerJSFHandler




Best Practices – “MVC-Like” Software ArchitectureBest 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

web jsf overview – dynamic content web pages – for egl/jsf developers

Documents