How to Configure Managed Beans for the Train Model

Working with Navigation Components 18-47 list-entries managed-bean The list-entries element contains the managed bean names for the train stops excluding subprocess train stops in value expressions for example, {train1}, listed in the order that the stops should appear on the train. 3. Configure a managed bean to create the train tree model from the train list. The train tree model wraps the entire train list, including any subprocess train lists. The train model managed bean should be instantiated with a childProperty value that is the same as the property name that represents the list of subprocess train children see Example 18–22 . Example 18–24 Managed Bean for Train Tree Model managed-bean managed-bean-nametrainTreemanaged-bean-name managed-bean-class org.apache.myfaces.trinidad.model.ChildPropertyTreeModel managed-bean-class managed-bean-scopenonemanaged-bean-scope managed-property property-namechildPropertyproperty-name valuechildrenvalue managed-property managed-property property-namewrappedDataproperty-name value{trainList}value managed-property managed-bean The childProperty property defines the property name to use to get the child list entries of each train stop that has a subprocess train. The wrappedData property value is the train list instance to wrap, created by the managed bean in Step 2. 4. Configure a managed bean to create the train model from the train tree model. This is the bean to which the train component on each page is bound. The train model wraps the train tree model. The train model managed bean should be instantiated with a viewIdProperty value that is the same as the property name that represents the pages associated with the train stops. Example 18–25 shows sample managed bean code for a train model. Example 18–25 Managed Bean for Train Model managed-bean managed-bean-nametrainMenuModelmanaged-bean-name managed-bean-class org.apache.myfaces.trinidad.model.ProcessMenuModel managed-bean-class managed-bean-scopesessionmanaged-bean-scope managed-property property-nameviewIdPropertyproperty-name valueviewIdvalue managed-property managed-property property-namewrappedDataproperty-name value{trainTree}value 18-48 Web User Interface Developers Guide for Oracle Application Development Framework managed-property -- to enable plusOne behavior instead, comment out the maxPathKey property -- managed-property property-namemaxPathKeyproperty-name valueTRAIN_DEMO_MAX_PATH_KEYvalue managed-property managed-bean The viewIdProperty property value is set to the property that is used to specify the page to navigate to when the user clicks the train stop. The wrappedData property value is the train tree instance to wrap, created by the managed bean in Step 3. The maxPathKey property value is the value to pass into the train model for using the Max Visited train behavior. ADF Faces uses the Max Visited behavior when a non-null maxPathKey value is passed into the train model. If the maxPathKey value is null, then ADF Faces uses the Plus One behavior.

18.8.3 How to Bind to the Train Model in JSF Pages

Each stop in the train corresponds to one JSF page. On each page, you use one train component and optionally a trainButtonBar component to provide buttons that allow the user to navigate through the train. To bind the train component to the train model: 1. Create a train component by dragging and dropping a Train from the Component Palette to the JSF page. Optionally drag and drop a Train Button Bar. 2. Bind the component. If your MenuModel implementation for a train model returns a rowData object similar to the public abstract class oracle.adf.view.rich.model.TrainStopModel, you can use the simplified form of train binding in the train components, as shown in the following code: af:train value={trainMenuModel} af:trainButtonBar value={trainMenuModel} The trainMenuModel in the EL expression is the managed bean name for the train model see Example 18–25 . If you cannot use the simplified binding, you must bind the train value to the train model bean, manually add the nodeStamp facet to the train, and to that, add a commandNavigationItem component, as shown in Example 18–26 . Example 18–26 Metadata to Bind a Train Component to the Train Model Bean af:train value={aTrainMenuModel} var=stop f:facet name=nodeStamp af:commandNavigationItem text={stop.label} action={stop.outcome} ... af:commandNavigationItem f:facet af:train 19 Creating and Reusing Fragments, Page Templates, and Components 19-1 19 Creating and Reusing Fragments, Page Templates, and Components This chapter describes how you can create reusable content and then use that content to build portions of your JSF pages or entire pages. This chapter includes the following sections: ■ Section 19.1, Introduction to Reusable Content ■ Section 19.2, Using Page Fragments ■ Section 19.3, Using Page Templates ■ Section 19.4, Using Declarative Components ■ Section 19.5, Adding Resources to Pages

19.1 Introduction to Reusable Content

As you build JSF pages for your application, some pages may become complex and long, making editing complicated and tedious. Some pages may always contain a group of components arranged in a very specific layout, while other pages may always use a specific group of components in multiple parts of the page. And at times, you may want to share some parts of a page or entire pages with other developers. Whatever the case is, when something changes in the UI, you have to replicate your changes in many places and pages. Building and maintaining all those pages, and making sure that some sets or all are consistent in structure and layout can become increasingly inefficient. Instead of using individual UI components to build pages, you can use page building blocks to build parts of a page or entire pages. The building blocks contain the frequently or commonly used UI components that create the reusable content for use in one or more pages of an application. Depending on your application, you can use just one type of building block, or all types in one or more pages. And you can share some building blocks across applications. When you modify the building blocks, the JSF pages that use the reusable content are automatically updated as well. Thus, by creating and using reusable content in your application, you can build web user interfaces that are always consistent in structure and layout, and an application that is scalable and extensible. ADF Faces provides the following types of reusable building blocks: ■ Page fragments: Page fragments allow you to create parts of a page. A JSF page can be made up of one or more page fragments. For example, a large JSF page can be broken up into several smaller page fragments for easier maintenance. For 19-2 Web User Interface Developers Guide for Oracle Application Development Framework details about creating and using page fragments, see Section 19.2, Using Page Fragments. ■ Page templates: By creating page templates, you can create entire page layouts using individual components and page fragments. For example, if you are repeatedly laying out some components in a specific way in multiple JSF pages, consider creating a page template for those pages. When you use the page template to build your pages, you can be sure that the pages are always consistent in structure and layout across the application. For details about creating and using page templates, see Section 19.3, Using Page Templates, and Section 19.3.3, How to Create JSF Pages Based on Page Templates. ■ Declarative components: The declarative components feature allows you to assemble existing, individual UI components into one composite, reusable component, which you then declaratively use in one or more pages. For example, if you are always inserting a group of components in multiple places, consider creating a composite declarative component that comprises the individual components, and then reusing that declarative component in multiple places throughout the application. Declarative components can also be used in page templates. For details about creating and using declarative components, see Section 19.4, Using Declarative Components. Page templates, declarative components, and regions implement the javax.faces.component.NamingContainer interface. At runtime, in the pages that consume reusable content, the page templates, declarative components, or regions create component subtrees, which are then inserted into the consuming page’s single, JSF component tree. Because the consuming page has its own naming container, when you add reusable content to a page, take extra care when using mechanisms such as partialTargets and findComponent, as you will need to take into account the different naming containers for the different components that appear on the page. For more information about naming containers, see Section 3.5, Locating a Client Component on a Page. If you plan to include resources such as CSS or JavaScript, you can use the af:resource tag to add the resources to the page. If this tag is used in page templates and declarative components, the specified resources will be added to the consuming page during JSP execution. For more information, see Section 19.5, Adding Resources to Pages.

19.2 Using Page Fragments

As you build web pages for an application, some pages may quickly become large and unmanageable. One possible way to simplify the process of building and maintaining complex pages is to use page fragments. Large, complex pages broken down into several smaller page fragments are easier to maintain. Depending on how you design a page, the page fragments created for one page may be reused in other pages. For example, suppose different parts of several Tip: If your application uses the ADF Controller and the ADF Model layer, then you can also use ADF regions. Regions used in conjunction with ADF bounded task flows, encapsulate business logic, process flow, and UI components all in one package, which can then be reused throughout the application. For complete information about creating and using ADF bounded task flows as regions, see the Using Task Flows as Regions chapter of the Oracle Fusion Middleware Fusion Developers Guide for Oracle Application Development Framework. Creating and Reusing Fragments, Page Templates, and Components 19-3 pages use the same form, then you might find it beneficial to create page fragments containing those components in the form, and reuse those page fragments in several pages. Deciding on how many page fragments to create for one or more complex pages depends on your application, the degree to which you wish to reuse portions of a page between multiple pages, and the desire to simplify complex pages. Page fragments are incomplete JSF pages. A complete JSF page that uses ADF Faces must have the document tag enclosed within an f:view tag. The contents for the entire page are enclosed within the document tag. A page fragment, on the other hand, represents a portion of a complete page, and does not contain the f:view or document tags. The contents for the page fragment are simply enclosed within a jsp:root tag. When you build a JSF page using page fragments, the page can use one or more page fragments that define different portions of the page. The same page fragment can be used more than once in a page, and in multiple pages. For example, the File Explorer application uses one main page index.jspx that includes the following page fragments: ■ popups.jspx: Contains all the popup code used in the application. ■ help.jspx: Contains the help content. ■ header.jspx: Contains the toolbars and menus for the application. ■ navigators.jspx: Contains the tree that displays the folder hierarchy of the application. ■ contentViews.jspx: Contains the content for the folder selected in the navigator pane. Example 19–1 shows the abbreviated code for the included header.jspx page fragment. Note that it does not contain an f:view or document tag. Example 19–1 header.jspx Page Fragment ?xml version=1.0 encoding=UTF-8? jsp:root xmlns:jsp=http:java.sun.comJSPPage version=2.0 xmlns:af=http:xmlns.oracle.comadffacesrich xmlns:f=http:java.sun.comjsfcore af:panelStretchLayout id=headerStretch f:facet name=center -- By default, every toolbar is placed on a new row -- af:toolbox id=headerToolbox binding={explorer.headerManager.headerToolbox} . . . af:toolbox f:facet af:panelStretchLayout jsp:root Note: The view parts of a page fragments, declarative components, and the main page all share the same request scope. This may result in a collision when you use the same fragment or declarative component multiple times on a page and the fragments or components share a backing bean. For more information about scopes, see Section 4.6, Object Scope Lifecycles.