What You May Need to Know About Using an LOV Component and the Optimized Lifecycle

Using the JSF Lifecycle with ADF Faces 4-13 component as a partial trigger for the input component and creating a method for the ValueChangeListener, you need to create a listener for the ReturnPopupEvent. This listener must programmatically set the input components as partial targets for the LOV. You do not need to set the LOV’s immediate attribute to true because the input component is no longer a target for the LOV until the ReturnPopupListener method is executed, and so it will not fail validation because the lifecycle will not be run on it. And because a listener method is used for the ReturnPopupEvent instead of for the ValueChangeEvent, both events can be queued and the model updated appropriately. Example 4–8 shows the needed page code for the LOV and input components. Example 4–8 af:inputListOfValues label=Ename id=lov1 value={validateLOV.ename} autoSubmit=true returnPopupListener={validate.processReturnPopup} Title=Search and Select: Ename searchDesc=Choose a name model={validateLOV.listOfValuesModel} validator={validateLOV.validate} af:inputText label=Empno value={validateLOV.empno} required=true id=lovDependent1 binding={validate.lovDependent1} The input component uses its binding attribute to store the instance on a backing bean, allowing the instance to be accessed by the listener method. The listener method then accesses the input component and sets it as a partial target for the LOV, as shown in Example 4–9 . Example 4–9 AdfFacesContext.getCurrentInstance.addPartialTarget_lovDependent1 For more information about programmatically setting partial page rendering, see Section 7.3, Enabling Partial Page Rendering Programmatically.

4.4 Using the Client-Side Lifecycle

The ADF Faces framework provides client-side conversion and validation. You can create your own JavaScript-based converters and validators that run on the page without a trip to the server. You can use client-side validation so that when a specific client event is queued, it triggers client validation of the appropriate form or subform for more information about subforms, see Section 4.5, Using Subforms to Create Regions on a Page . If this client validation fails, meaning there are known errors, then the events that typically propagate to the server for example, a command buttons actionEvent when a form is submitted do not go to the server. Having the event not delivered also means that nothing is submitted and therefore, none of the client listeners is called. This is similar to server-side validation in that when validation fails on the server, the lifecycle jumps to the Render Response phase; the action event, though queued, will never be delivered; and the actionListener handler method will never be called. For example, ADF Faces provides the required attribute for input components, and this validation runs on the client. When you set this attribute to true, the framework will show an error on the page if the value of the component is null, without requiring a trip to the server. Example 4–10 shows code that has an inputText component’s required attribute set to true, and a command button whose actionListener attribute is bound to a method on a managed bean. 4-14 Web User Interface Developers Guide for Oracle Application Development Framework Example 4–10 Simple Client-Side Validation Example af:form af:inputText id=input1 required=true value=a af:commandButton text=Search actionListener={demoForm.search} af:form When this page is run, if you clear the field of the value of the inputText component and tab out of the field, the field will redisplay with a red outline. If you then click into the field, an error message will state that a value is required, as shown in Figure 4–10 . There will be no trip to the server; this error detection and message generation is all done on the client. Figure 4–10 Client-Side Validation Displays an Error Without a Trip to the Server In this same example, if you were to clear the field of the value and click the Search button, the page would not be submitted because the required field is empty and therefore an error occurs; the action event would not be delivered, and the method bound to the action listener would not be executed. This process is what you want, because there is no reason to submit the page if the client can tell that validation will fail on the server. For more information about using client-side validation and conversion, see Chapter 6, Validating and Converting Input.

4.5 Using Subforms to Create Regions on a Page

In the JSF reference implementation, if you want to independently submit a region of the page, you have to use multiple forms. However multiple forms require multiple copies of page state, which can result in the loss of user edits in forms that arent submitted. ADF Faces adds support for a subform component, which represents an independently submittable region of a page. The contents of a subform will be validated or otherwise processed only if a component inside of the subform is responsible for submitting the page, allowing for comparatively fine-grained control of the set of components that will be validated and pushed into the model without the compromises of using entirely separate form elements. When a page using subforms is submitted, the page state is written only once, and all user edits are preserved. A subform will always allow the Apply Request Values phase to execute for its child components, even when the page was submitted by a component outside of the subform. However, the Process Validations and Update Model Values phases will be skipped this differs from an ordinary form component, which, when not submitted, cannot run the Apply Request Values phase. To allow components in subforms to be processed through the Process Validations and Update Model Value phases when a component outside the subform causes a submit action, use the default attribute. When a subform’s default attribute is set to true, it acts like any other subform in Best Practice: Always use only a single form tag per page. Use the subform tag where you might otherwise be tempted to use multiple form tags. Using the JSF Lifecycle with ADF Faces 4-15 most respects, but if no subform on the page has an appropriate event come from its child components, then any subform with default set to true will behave as if one of its child components caused the submit. For more information about subforms, see Section 9.2, Defining Forms.

4.6 Object Scope Lifecycles

At runtime, you pass data to pages by storing the needed data in an object scope where the page can access it. The scope determines the lifespan of an object. Once you place an object in a scope, it can be accessed from the scope using an EL expression. For example, you might create a managed bean named foo, and define the bean to live in the Request scope. To access that bean, you would use the expression {requestScope.foo}. There are three types of scopes in a standard JSF application: ■ applicationScope: The object is available for the duration of the application. ■ sessionScope: The object is available for the duration of the session. ■ requestScope: The object is available for the duration between the time an HTTP request is sent until a response is sent back to the client. In addition to the standard JSF scopes, ADF Faces provides the following scopes: ■ pageFlowScope: The object is available as long as the user continues navigating from one page to another. If the user opens a new browser window and begins navigating, that series of windows will have its own pageFlowScope scope. ■ backingBeanScope: Used for managed beans for page fragments and declarative components only. The object is available for the duration between the time an HTTP request is sent until a response is sent back to the client. This scope is needed because there may be more than one page fragment or declarative component on a page, and to avoid collisions between values, any values must be kept in separate scope instances. Use backingBeanScope scope for any managed bean created for a page fragment or declarative component. ■ viewScope: The object is available until the ID for the current view changes. Use viewScope scope to hold values for a given page. Object scopes are analogous to global and local variable scopes in programming languages. The wider the scope, the higher the availability of an object. During their lifespan, these objects may expose certain interfaces, hold information, or pass variables and parameters to other objects. For example, a managed bean defined in sessionScope scope will be available for use during multiple page requests. However, a managed bean defined in requestScope scope will be available only for the duration of one page request. Figure 4–11 shows the time period in which each type of scope is valid, and its relationship with the page flow. Note: Because these are not standard JSF scopes, EL expressions must explicitly include the scope to reference the bean. For example, to reference the MyBean managed bean from the pageFlowScope scope, your expression would be {pageFlowScope.MyBean}.