This session provides an overview of the JSF-based controller on ADF 11g - the ADF Controller. The session provides an overview of the extensions implemented by Oracle to the standard JSF controller that make the ADF Controller.
Developer Data Modeling Mistakes: From Postgres to NoSQL
Silicon Valley Code Camp - JSF Controller for Reusability
1.
2. Extending the JSF Controller for Reusability Juan Camilo Ruiz Principal Product Manager JDeveloper Team
3. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
Develop Applications with Oracle ADF 16 - JSF Life Cycle The life cycle of a JavaServer Faces page is similar to that of a JSP: The client makes an HTTP request for the page, and the server responds with the page translated to HTML. However, because of the extra features that JavaServer Faces technology offers, the life cycle provides some additional services to process a page. A JavaServer Faces page is represented by a tree of UI components, called a view. This tree is a run-time representation of a JSF page. Each UI component tag in a page corresponds to a UI component instance in the tree. The FacesServlet object manages the request processing lifecycle in JSF applications. FacesServlet creates an object called FacesContext , which contains the information necessary for request processing, and invokes an object that executes the lifecycle. When a client makes a request for the page, the life cycle starts. During the life cycle, the JSF implementation must build the view while considering state saved from the previous postback. When the client performs a postback of the page, the JavaServer Faces implementation performs several tasks, such as validating the data input of components in the view and convertin input data to types specified on the server side. The JSF implementation performs all of these tasks as a series of steps in the life cycle.
Develop Applications with Oracle ADF 16 - Coordination of JSF and ADF Lifecycles When a page is submitted and a new page requested, the application invokes both the JSF request lifecycle and the ADF page lifecycle. The JSF lifecycle handles the submission of values on the page, validation for components, navigation, and displaying the components on the resulting page and saving and restoring state. The JSF lifecycle phases use a UI component tree to manage the display of the faces components. This tree is a runtime representation of a JSF page: each UI component tag in a page corresponds to a UI component instance in the tree. The FacesServlet object manages the request processing lifecycle in JSF applications. FacesServlet creates an object called FacesContext , which contains the information necessary for request processing, and invokes an object that executes the lifecycle. The ADF lifecycle handles preparing and updating the data model, validating the data at the model layer, and executing methods on the business layer. The ADF lifecycle uses the binding container to make data available for easy referencing by the page during the current page request. The ADF lifecycle also contains phases that are defined simply to notify ADF lifecycle listeners before and after the corresponding JSF phase is executed (that is, there is no implementation for these phases). This allows you to create custom listeners and register them with any phase of both the JSF and ADF lifecycles, so that you can customize the ADF page lifecycle if needed, both globally or at the page level.
Using URL View Activites To display the resource, you must specify an EL expression that is evaluated at run-time to generate the URL to the resource. In addition, you can specify EL expressions that, when evaluated, are added as parameters and parameter values to the URL. A URL view activity redirects the client regardless of the view port (root view port or an ADF region) from which it is executed. The <redirect> element of a view activity performs in a similar way, except it can be used only if the view activity is within the root view port.
Bookmarking View Activities You can enable users to easily return to a view activity in an unbounded task flow by designating the activity as bookmarkable. On the Bookmark tab of the Property Inspector you can set the bookmark property to true . You can optionally add parameters in the URL Parameters section and can add an optional method binding in the converter field for a parameter’s value. You can also optionally specify a method in the method field that the ADF Controller should invoke before rendering the view. You could use this method to retrieve additional information based on the parameter values. Instead of making the view activity bookmarkable, you may choose to use the redirect option to create a new browser URL for the view activity. You do this by setting the redirect property to true on the Common tab of the Property Inspector for the view activity.
Passing Parameters to an ADF Bounded Task Flow A called ADF bounded task flow can accept input parameters from another ADF unbounded or bounded task flow and can pass return values to the caller upon exit. You can specify on the input parameter definition for the called bounded task flow whether an input parameter is required. If a required input parameter is not received, a runtime error occurs. An input parameter definition that is identified as not required can be ignored during task flow call activity creation.
Reentering an ADF Bounded Task Flow To deal with cases in which the end user clicks the back button to navigate back into an ADF bounded task flow that was already exited, you can specify task-flow-reentry options for the task flow definition. These options specify whether a page in the calling ADF bounded task flow can be reentered. Upon reentry, ADF bounded task flow input parameters are evaluated using the current state of the application, not the application state existing at the time of the original ADF bounded task flow entry.