.JSP Page Flow – and Managing State in your Web Application

1. .JSP Page Flow – and Managing State in your Web Application This learning module covers the salient features of managing transaction and state in your dynamic content web application. It also covers page flow and forwarding options, request and session page beans.

2. JSF/EGL Web Page and Site Design and Development Course Units: • Course Setup • Web/JSF Overview • JSF Properties Deep Dive • Essential JSF Components • Additional JSF Components • JSF dataTables • Page Flow and State Management • AJAX Controls and JavaScript • JSF Component Tree and Dynamic Property Setting • Web-Site Design and Template Pages • Appendices • Internationalization • Page Design Best Practices • Additional Use Cases

3. Unit Objectives At the end of this unit, you will be able to: • State and describe the different state management options: • Application • Session • Request • State the functions and benefits of Forwarding options in EGL/RBD: • JSF • Link • Command Link • Submit • EGL • Forward • Forward to URL • HTML Links • Native HTML anchor tags • Graphically describe page flow using Links view • Create your own JSF pages initializing State and Forwarding features

4. Web applications are considered “state-less” - because they do not automatically save information about a user's interaction with the application. State management refers to the act of storing transaction data temporarily, and passing it among the various JSFHandlers in your application. There are three options (in descending order of scope (the variable’s lifetime): Application variables – which allow you to store data in application server “application” objects, such that any JSFHandler can access the variable data while the server is “up” Session variables – which allow you to store data in application server session objects Request variables – which allow you to store and forward data to pages in the URLs The differences between these approaches is as follows: Application variables are set and maintained in and by the application server for data that is meant to be “globally available” to all JSFHandlers throughout an application The are not view-able Once they are set, unless they are unset by an EGL system library call, their values are extant until the server is brought down Session variables are stored in the application server’s memory Variables are not view-able (in the URL) Request variables are passed as value-pair strings in the URL. They are viewable – and can be seen by hackers (although they can be encrypted) Their lifecycle (scope) ends when the launched page is rendered Let’s look at the EGL statements to invoke these options. State Management Options

5. State Management Options – j2eeLib Statement Structure • From this screen shot (of Content Assist) you can see the three basic categories of statements (and note that these apply to all three types of variables): • clear – remove the variable from application server’s memory • set – initialize the value of an variable in server memory to a JSFHandler variable value • get – return the value of an variable from the server to the JSFHandler • A few notes on the two exceptions to the above syntax structure: • clearEGLSessionAttrs() – removes all Session attributes set in your JSFHandler • getQueryParameter() – is used with AJAX controls – a topic we will cover later in this course

6. State Management Options – “Application” Variables Application variables are • “set” • And written to the application server’s memory • “get” • And retrieved from the application server’s memory • Their scope lifetime is: • Your application removes the variable clearApplicationAttr() • Until the server is brought down (stopped) Notes: • Application attributes are “global” to all JSFHandlers • As such, they should contain only information that should be made available at that level of scope • As a best practice, one JSFHandler sets – and the rest get Application Server (WebSphere) JSFHandler1 setApplicationAttr(…) Application Variable Data JSFHandler2 getApplicationAttr(…) JSFHandler3 getApplicationAttr(…) JSFHandler4 getApplicationAttr(…) JSFHandler…n getApplicationAttr(…)

7. State Management Options – Session Variables Session variables are • “set” • And written to the application server’s memory • “get” • And retrieved from the application server’s memory Their scope (lifetime) is: • Your application removes the variable clearSessionAttr(…) clearEGLSessionAttrs() • The user redirects his browser to another server – from a forward statement within EGL. • Until an internal session time-out occurs (typically 10 minutes) ***Notes

8. State Management Options – Request Variables Request variables are • “set” • And written to the application server’s memory using: setRequestAttr Forward <var> • “get” • And retrieved from the application server’s memory Their scope (lifetime) is: • Your application removes the variable clearRequestAttr() • The user redirects his browser to another PAGE Application Server JSFHandler1 setRequestAttr(…) Request Variable Data JSFHandler2 getRequestAttr(…) JSFHandler3 Forward var1 to “…” Request Variable Data JSFHandler4 onConstruction(var1…)

9.  There are three types of page forwarding (launch this new page) options in EGL/RBD HTML Links Using native HTML anchor tags, you can launch any valid URL <A href="http://localhost:9081/EGLWeb/allsiteusers.faces">Site Users</A>. See also this <A ref="../images/ibm.gif"> link on top of an image</A> JSF Links Using the JSF Link component, you can add one of the above HTML anchor tags to dynamic data content – including passing values as parameters Form Submit (and EGL forward) Using Submit Buttons and Link-Command tags, you invoke an EGL Function. From which you may FORWARD (to any page in a project in your workspace), or FORWARD TO URL to any page on the Internet There are many variations on these options, and the options can be combined. The next slide explains and categorizes this. Page Forwarding Options

10. Options (Details)

11. JSFHandler Pages and State Management • Your pages are defined in faces-config.xmlwith a “scope” which controls how long the JSFHandlers (JavaBeans – aka “managed beans”) exist in the application server’s storage at run-time. • The default scope for new EGL JSFHandlers is: “session” – which means the JavaBeans persist while the user is logged into the application, or until some pre-set server timeout is reached (typically 10 minutes). • An additional scope is “request” – which forces the server to remove the JavaBean as soon as the page is rendered. This is important! Let’s dig into it a bit… WebSphere Application Server JSFHandler-1 Forward to…What happens to the JSFHandler-1 JavaBean in server storage? JSFHandler-2

12. JSFHandlers in session Scope • When you create a new web (.jsp) page in an EGL/Web project, the tooling enters a default scope of “session” in faces-config.xml. This means the following happens at run-time with each JavaBean that is instantiated (loaded from disk into server memory): JSPPage-1 WebSphere Application Server • onConstruction() • The JSFHandler-1 JavaBean remains • memory for ~10 minutes, or until • the user leaves the application JSFHandler-1 2. Forward or Link JSPPage-2 JSFHandler-2 3. onConstruction() The JSFHandler-1 JavaBean remains memory for ~10 minutes, or until the user leaves the application

13. JSFHandlers in session Scope + cancelOnPageTransition=yes • Forcing the Application Server to maintain each instance of a JavaBean for up to 10 minutes or conceivably longer may not be the ideal situation for your server’s memory allocation. • If you add cancelOnPageTransition=yes to your JSFHandler properties, your page’s JavaBean will be removed from server memory – when the user launches the next page JSPPage-1 WebSphere Application Server 1. onConstruction() JSFHandler-1 2. Forward or Link 3. IF cancelOnPageTransition=yes JSFHandler-1 removed from Application Server memory. JSPPage-2 JSFHandler-2 4. onConstruction()

14. JSFHandlers in request Scope • For the optimal server memory performance, you should design your pages to save and return minimal data to/from the Application Server’s Session variables, and define your pages to be request scope. • For page’s in request scope, the JSFHandler bean is removed from the server at then end of the onConstruction() function. As you can imagine, this can save considerable memory. However, you will have to design your logic to support selective variable state management - especially if your page’s lifecycle involves multiple round-trips from the user’s browser to the server. JSPPage-1 WebSphere Application Server After onConstruction() the JavaBean is removed from server memory. Use setSessionAttr/getSessionAttr to persist data values temporarily JSFHandler-1 getSessionAttr setSessionAttr Forward or Link Session Variable Data JSPPage-2 JSFHandler-2 getSessionAttr setSessionAttr After onConstruction() the JavaBean is removed from server memory. Use settSessionAttr/getSessionAttr to persist data values temporarily

15. Maintaining State With Request Pages – 1 of 2 When initially loaded (if called from another page) request pages are no different than session scoped pages. However, when they are loaded because of a Form Submit, there are three things that you must understand when designing your request-scoped pages: • The JSFHandler function order • How to code logic that determines and handles onConstruction() logic when the page: • Is called from another page • Is called from a Form Submit • How to save and return selective variable values stored in Session***Notes JSFHandler function order for request pages (upon form submit) • For pages that interact iteratively with users (like a data entry form), when a page is in session scope, the function that is bound to a Submit button is executed in the JSFHandler. • And that is all. One click / submit? That function is invoked (and any other functions called from it) • In a page that is defined as request scope: When a user clicks a function: • The page is loaded into the server “from scratch” – as if the page was called by some other page’s link or forward to statement. All data variables have initial values (i.e. they do NOT maintain the values that existed before the page was rendered) • onConstruction() is executed • Then the function that is bound to the submit button is executed***see Notes*** JSFHandler 1. JSPPage JSFHandler WebSphere Application Server 2. onConstruction() … Form Submit   3. Function (bound to clicked Submit Button) … Submit

16. JSPPage Submit Maintaining State With Request Pages – 2 of 2 How to code EGL that determines and handles onConstruction() logic when the page: is called from another page …vs… is called from a Form Submit • Retrieve a session variable into an EGL variable. This variable will act as a flag for the lifecycle path • Code conditional logic that tests the EGL variable and takes appropriate action based on whether this is: Initial load (setup page variables) …or… Form Submit (interact with user) JSFHandler Link or Forward. URL contains parm Function onConstruction(parm int) … getsessionAttr(“saveKey”, saveVar); …or… FALSE TRUE (saveVar == 0) Initial Page Load Set key to parm First-time-in Business Logic Save values to Session Subsequent Page Load (Form Submit) Return keys from Session Submitted-Form onConstruction Logic Session Variable Pool Form Submit Page values return  WebSphere Application Server

17. Workshop – Request Page Form • You will • Create a new version of updatecustomer (updatecustomer3.jsp) • You will define it as request in scope • Copy/Paste standard request page business logic • Create the fields for the new page • Run and test and note from the console, the sequence/order of function execution • Modify two lines of code in the JSFHandler’s onConstruction function, that will demonstrate the interaction between page data and saved values, for pages in request scope • Re-test and validate your understanding of this technique • Note – this is a multi-step and non-trivial workshop, but very important for your complete understanding of this critical process

18.  Create updatecustomer3.jsp • From Project Explorer • Create a new Web Page: updatecustomer3.jsp • Use a template from the MyTemplates folder • Change the header text as shown  • Save (press Ctrl/S)

19. Updatecustomer3.egl • Replace the boiler-plate EGL statements with the code in the Notes section of this slide. • Press Ctrl/S • Read the comments carefully, and for understanding. • Especially of the: • getSessionAttr() • If test to determine which lifecycle phase • setSessionAttr() • clearSessionAttr()

20.  Add EGL Page Data to the .JSP Page • From Page Data: • Drag and Drop customer onto the Content Area: • Create Customer_ID as an output text control • Create the remainder of the fields as Input Text controls • Drag and Drop updateCustomerFunc() on the Content Area • Drag and Drop returnToAllCustomers2() on the Content Area • Drag and drop outputVar on the page as shown

21.  Add a New Link From allcustomers2.jsp • From Enhanced Faces Components • Add a link to CustomerID • URL: updatecustomer3.faces • From the new Link’s Properties • Add a Parameter • To customerArray.CustomerID

22.  Run On Server – Verify Results – 1 of 2 • Run and test allcustomers2 • From updatecustomer3 • Note the value of OutputVar • Change some data and press updateCustomerFunc • Your data should be saved – BUT NOTE – OutputVar no longer has data…why? (Because it is an output field and unlike CustID – is not saved to session between lifecycle phases) • Press returnToAllCustomers2 • Open the Console view • Read the ** writeStdOut(“messages”) and note the sequence/order of function execution in a request page

23.  Run On Server – Verify Results – 2 of 2 From updatecustomer3.egl – onConstruction() function: • Un-comment the statement that assigns outputVar on the Form Submit lifecycle phase (else path) • Comment out the statement that assigns customer.CustomerID to the saveKey; • Press Ctrl/S to save your edits Run allcustomers2.jsp and re-test the pages Note that the database update failed… why? Because the row’s primary key – which is not returned from the page because it is an output field – is missing in the record to be updated One other use case scenario to solve. If you run from allcustomers2 twice – within the same session, your updatecustomer3 page will not work correctly. Can you figure out why? (Read the Notes if you need help). To fix this, from allcustomers3.egl’s onConstruction() function, add: clearSessionAttr(“cidSession”);

24.  Workshop to Explore the use of JSF Request Links – 1 of 5 • It can be crucial for your application to provide conditional forwarding of a page to different target browser – after the page invokes an EGL function (ex. Write to a database, perform some calculations, etc.). • You can accomplish this requirement using the JSF Request Link.  From Project Explorer • Create a new Web Page: requestLinkPage.jsp • Use a template from the MyTemplates folder • Change the header text as shown • Save (press Ctrl/S) • Edit the EGL code. • Replace the entire JSFHandler for the page, with the contents in the Notes section of this slide (ensure that the page names match) • Save: Ctrl/S

25.  Workshop to Explore the use of JSF Request Links – 2 of 5 • Read for understanding, the comments in the JSFHandler Function that will open a page in a new browser frame Passing a parameter Function that will open a page in a browser frame named: “frame2” Also passing a parameter

26.  Workshop to Explore the use of JSF Request Links – 3 of 5 • From Page Designer – add the following: • Two JSF Request links. For each link: • Type representative label text • From All Attributes • Specify a target that accesses the associated EGL function: • An HTML Horizontal Rule • An HTML inline frame, named: frame2

27.  Workshop to Explore the use of JSF Request Links – 4 of 5 • Select each request link, and from the Properties/All Attributes view specify their respective action.

28.  Workshop to Explore the use of JSF Request Links – 5 of 5 • Run the page, and test out the Request links. Look in the console to see the messages written that confirm the EGL JSFHandler was invoked, before redirecting

29. OPTIONAL Workshop – Working with State and Forwarding Features • You will create several pages that demonstrate the language and tooling features just discussed. • Specifically: • state1.jsp – will demonstrate the linking and forwarding features, as well as initializing application/session/request attributes and forwarding to state2.jsp • state2.jsp – will receive and display the initialized application, session and request variables - and forward to state3.jsp • state3.jsp – will receive and display the same initialized application, session and request variables – and allow you to clear them, and forward back to state1.jsp  Forward state1.jsp state2.jsp state3.jsp Forward Forward set get get Application Variable Session Variable(s) Request Variable Application Server Forward/Links to other URLs

30.  Create state1.jsp Create a new page, named: state1.jsp - Replace the default code with the JSFHandler code in the slide Notes - Check out the following! - j2eelib.get functions - j2eelib.set functions - Several different forward options  Note also that the JSFHandler has the cancelOnPageTransition property

31.  State1.jsp Page – Server Attributes Section – 1 of 3 • Change the page header text • Add an HTML table to the page: • 16 Rows/2 columns/100% width • Combine cells in the top row, and add the text shown  • Rows 2  4 • Add the text that is shown in the left column • Drag JSF output controls in the right column • (From Page Data) Bind the variables as shown in the screen capture to the output controls • Combine cells in rows 5 and 6 • In the left column, rows 6 - 16 add the text as shown here In the right hand column: Row 7 – add an HTML link • Type:  File • Browse and select dataGraph.jsp • Change the .jsp extension to .faces Row 8 – add the ibm.gif graphic from \images\ • Right-click over the graphic and add an  HTTP link to: http://www.ibm.com • Note: To add an HTML link to a graphic. • Select (set focus to) the graphic • Right-click - and from the context menu • Select: Insert Link…

32.  State1.jsp Page – Server Attributes Section – 2 of 3 In the right hand column: Row 9 - add a JSF link • It’s URL should be: allorders.faces • Type the label as shown Row 10 – add a JSF Image From the Images Properties/File: Browse to: /images/ibm.gif • Drag and drop a JSF Link on top of the JSF Image control • It’s URL should be: http://www.ibm.com Row 11 – add a Link-Command From Properties/All Attributes specify an action that invokes: commandLinkFunc() • Select (click) the text portion of the Link and type the Value as shown  • Add a JSF output control next to the Link-Command • From Page Data, drag and drop cmdLink on top of the output control Row 12 – From Page Data, drag & drop submitButtonFunc() • Add a JSF output control next to the Submit Button created • From Page Data, drag and drop subButton on top of the output control

33.  State1.jsp Page – Server Attributes Section – 3 of 3 In the right hand column: Row 13 - From Page Data, drag and drop EGLForward() Row 14 - From Page Data, drag and drop EGLForwardRequest() Row 15 - From Page Data, drag and drop EGLForwardToURL() • Add a JSF input control next to the button • From Page Data, drag and drop city on top of the input control Row 15 - From Page Data, drag and drop setAttrsAndFwd() • Run the page on the server • Try out all of the options EXCEPT – setAttrsAndFwd() • We need to create a new page for that.

34.  Create state2.jsp Page • Create a new page, named: state2.jsp • Replace the default code with the JSFHandler code in the slide Notes. • Read through the EGL statements – note the: • J2eelib.get – statements • New U.I. record • EGL forwardto “state3” after setting a new session attribute value

35.  Design the state2.jsp Page • As you can see, this is a much simpler page than state1.jsp • Drag the rec - uiRecSession variable on the page. • Create output fields • Optionally • Customize the labels • Select the entire HTML table and give it a border: 1 • Drag the forwardToState3() function on the page

36.  Create state3.jsp Page • Create a new page, named: state3.jsp. Replace the default code with the JSFHandler code in the slide Notes. • Read through the EGL statements • Note the: • J2eelib.get – statements • J2eelib.clear – statements • Forward to state1.jsp

37.  Design the state3.jsp Page As you can see, this is also a much simpler page than state1.jsp • Drag the rec - UIRecSession variable on the page. • Create output fields. Optionally customize the labels • Add an HTML Horizontal Rule • Drag • clearApplicationAttr() • clearSingleSessionAttr() • forwardToState1() …functions on the page, to create the submit buttons shown

38.  Run the Pages (starting from state1.jsp) • Run state1.jsp. Click setAttrsAndFwd. Check out the values in the state variables. Launch state3.jsp. Try out the clear functions. Go back to state1.jsp (Note that (unless you cleared them) the Application and Session attributes are still available and will show up on state1.jsp – why?)

39.  Page Links View – state1.jsp The web tooling can show you all of your JSF page links (notably, not the EGL forward), including: • Templates • .CSS files • Graphics • # of references • HTML links • JSF links • Navigation links • Website-navigator • See next slide Try it out! From the Window menu …select • Show View • Links

40.  Page Links View – menu.jsp Try looking at menu.jsp, or allcustomers2.jsp in the Links view (with the Links view open, just click the page name in Project Explorer) 

41. Unit Summary • Now that you have completed this unit, you should have: • Stated and described the different state management options: • Application • Session • Request • Listed the functions and benefits of Forwarding options in EGL/RBD: • JSF • Link • Command Link • Submit • EGL • Forward • Forward to URL • HTML Links • Native HTML anchor tags • Used Links View to graphically describe page flow • Created your own JSF pages, and initialized State and Forwarding features