What Happens When You Create a Backing Bean Validation Method How to Create a Custom JSF Validator

6-16 Web User Interface Developers Guide for Oracle Application Development Framework Example 6–14 shows a custom validator tag nested inside an inputText component. Note that the tag attributes are used to provide the values for the validator’s properties that were declared in the faces-config.xml file. Example 6–14 A Custom Validator Tag on a JSF Page h:inputText id=empnumber required=true hdemo:emValidator emPatterns=9999|9 9 9 9|9-9-9-9 h:inputText To use a custom validator without a custom tag: To use a custom validator without a custom tag, nest the validator’s ID as configured in faces-config.xml file inside the f:validator tag. The validator’s ID attribute supports EL expression such that the application can dynamically determine the validator to use. 1. From the Structure window, right-click the input component for which you want to add validation, and choose Insert inside component ADF Faces Core Validator .

2. Select the validator’s ID from the dropdown list and click OK.

JDeveloper inserts code on the JSF page that makes the validator ID a property of the f:validator tag. Example 6–15 shows the code on a JSF page for a validator using the f:validator tag. Example 6–15 A Custom Validator Nested Within a Component on a JSF Page af:inputText id=empnumber required=true f:validator validatorID=emValidator af:inputText

6.6.4 What Happens When You Use a Custom JSF Validator

When you use a custom JSF validator, the application accesses the validator class referenced in either the custom tag or the f:validator tag and executes the validate method. This method accesses the data from the component in the current FacesContext and executes logic against it to determine if it is valid. If the validator has attributes, those attributes are also accessed and used in the validation routine. Like standard validators, if the custom validation fails, associated messages are placed in the message queue in the FacesContext instance. 7 Rerendering Partial Page Content 7-1 7 Rerendering Partial Page Content This chapter describes how to use the partial page render features provided with ADF Faces components to rerender areas of a page without rerendering the whole page. This chapter includes the following sections: ■ Section 7.1, Introduction to Partial Page Rendering ■ Section 7.2, Enabling Partial Page Rendering Declaratively ■ Section 7.3, Enabling Partial Page Rendering Programmatically ■ Section 7.4, Using Partial Page Navigation

7.1 Introduction to Partial Page Rendering

AJAX Asynchronous JavaScript and XML is a web development technique for creating interactive web applications, where web pages appear more responsive by exchanging small amounts of data with the server behind the scenes, without the whole web page being rerendered. The effect is to improve a web pages interactivity, speed, and usability. With ADF Faces, the feature that delivers the AJAX partial page render behavior is called partial page rendering PPR. PPR allows certain components on a page to be rerendered without the need to rerender the entire page. For example, an output component can display what a user has chosen or entered in an input component, or a command link or button can cause another component on the page to be rerendered, without the whole page rerendering. In order for PPR to work, boundaries must be set on the page that allow the lifecycle to run just on components within the boundary. In order to determine the boundary, the framework must be notified of the root component to process. The root component can be identified in two ways: ■ Events: Certain events indicate a component as a root. For example, the disclosure event sent when expanding or collapsing a showDetail component see Section 8.8, Displaying and Hiding Contents Dynamically , indicates that the showDetail component is a root. When the showDetail component is expanded or collapsed, only that component goes through the lifecycle. Other examples of events identifying a root component are the disclosure event when expanding nodes on a tree, or the sort event on a table. ■ Components: Certain components are recognized as a boundary, and therefore a root component. For example, the framework knows a popup dialog is a boundary. No matter what event is triggered inside a dialog, the lifecycle does not run on components outside the dialog. It runs only on the popup. 7-2 Web User Interface Developers Guide for Oracle Application Development Framework In addition to built-in PPR functionality, you can configure components to use cross-component rendering, which allows you to set up dependencies so that one component acts as a trigger and another as the listener. When an event occurs on the trigger component, the lifecycle is run only on listener components and child components to the listener, and only the listener components and their children are rerendered. Cross-component rendering can be implemented declaratively. However, by default, all events from a trigger component will cause PPR note that some components, such as table, trigger partial targets on only a subset of their events. For these cases where you need strict control over the event that launches PPR, or for cases where you want to use some logic to determine the target, you can implement PPR programatically. Additionally, ADF Faces applications can use PPR for navigation. In standard JSF applications, the navigation from one page to the next requires the new page to be rendered. When using AJAX-like components, this can cause overhead because of the time needed to download the different JavaScript libraries and style sheets. To avoid this costly overhead, the ADF Faces architecture can optionally simulate full-page transitions while actually remaining on a single page, thereby avoiding the need to reload JavaScript code and skin styles.

7.2 Enabling Partial Page Rendering Declaratively

Using the simplest form of cross-component rendering, one component, referred to as the target component, is rerendered when any event occurs on another component, referred to as the trigger component. For example, as shown in Figure 7–1 , the File Explorer application contains a table that shows the search results in the Search panel. This table and only this table is rerendered when the search button is activated. The search button is configured to be the trigger and the table is configured to be the target. Tip: If your application uses the Fusion technology stack, you can enable the automatic partial page rendering feature on any page. This causes any components whose values change as a result of backend business logic to be automatically rerendered. For more information, see the What You May Need to Know About Automatic Partial Page Rendering section of the Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework. Note: The browser must have JavaScript enabled for PPR to work.