Applying JavaServer Faces in Java

Drawer ECC200 in Java Applying JavaServer Faces

writerendElement("td"); writerendElement("tr"); writerendElement("table"); } private void encodeAllComponent(FacesContext context, UIComponent component) throws IOException { // suppress rendering if "rendered" property on the component is // false if (!componentisRendered()) { return; } // Render this component and its children recursively componentencodeBegin(context); if (componentgetRendersChildren()) { componentencodeChildren(context); } else { Iterator kids = getChildren(component); while (kidshasNext()) { UIComponent kid = (UIComponent) kidsnext(); encodeAllComponent(context, kid); } } componentencodeEnd(context); } protected Iterator getChildren(UIComponent component) { List results = new ArrayList(); Iterator kids = componentgetChildren()iterator(); while (kidshasNext()) { UIComponent kid = (UIComponent) kidsnext(); if (kidisRendered()) { resultsadd(kid); } } return (resultsiterator()); }

The first thing to note is that this component returns true from getRendersChildren( ) This tells the Faces runtime that this component is taking responsibility for rendering its children (See 10 for more on the getRendersChildren( ) method) The encodeBegin( ) method simply takes the password component, provided by the user via the passwordComponent binding attribute, and sets its redisplay property to true Without this property being set, JSF can t populate this field automatically with the saved password Note that the more natural place to set the redisplay property is in the buildLoginComponents( ) method, but the property cannot be set there because the component binding doesn t happen until the setProperties( ) method is called, which happens after the component is instantiated The encodeChildren( ) is overridden to take no

15:

action because that logic has been deferred to encodeEnd( ) encodeEnd( ) is where all the real work happens, which is broken down into two submethods: performCookieProcessing( ) and performRendering( ) performCookieProcessing( ) first clears the login panel and checkbox Then it uses the ExternalContext s CookieMap, which exposes the cookies sent by the browser as a Map, to check for the existence of the cookie named by the value of the constant COOKIE_NAME Note again that the cookie name is prefixed with comjsfcompref to guard against the chance of overwriting someone else s cookie If the cookie named COOKIE_NAME exists, and has a positive length, we can assume it was placed there by this component on a prior request, and then must set the value of the checkbox to be true The cookie is then taken apart and the username and password extracted, and set as the current value of the username and password components Note that these values are saved in unencrypted clear text for this example, but a production solution will need to provide encryption for the data If the cookie does not exist, performCookieProcessing( ) takes no action performRendering( ) is very similar to the encodeBegin( ) method of FormBasedLoginComponent The main difference is that actual UIComponents are used to handle the rendering of the actual text fields, buttons, and the checkbox The encodeAllComponent( ) helper method handles this delegation by recursively rendering the children of the argument component while honoring the rendersChildren setting of each child The decode processing of the input fields and the button is handled by the JSF runtime because these components are added to the tree We don t need to explicitly decode them ourselves The postback cookie processing is deferred to the RenderResponse phase using a PhaseListener, described next, but one crucial step must be taken during the normal decode( ) as is shown in the following

public void decode(FacesContext context) { contextgetExternalContext()getRequestMap()put(COOKIE_NAME, } this);

Here the actual RememberMeLoginComponent instance is stored in the RequestMap so the PhaseListener can have access to it in a threadsafe manner This is necessary because a single PhaseListener instance is used for all requests from all users in the application, and therefore must be thread safe Since the Servlet specification guarantees that request processing all happens on a single thread, the RequestMap is a great place to store things that need to be thread safe