This chapter includes the following sections:
With the customization features provided by Oracle Metadata Services (MDS), both developers and customers can customize Oracle Fusion applications. Customizing an application involves taking a generalized application and making modifications to suit the needs of a particular group, such as a specific industry or site.
When an application is customizable, an end user can customize a user interface page at runtime in several ways. For example, the user can use the following methods to customize a page:
Implicitly: Implicit customizations occur when a customer changes certain component attributes, such as the size of a panel or whether detail content is displayed.
Using Page Composer: Page Composer enables end users who have the correct permissions, such as administrators, to change a user interface page to suit their company's needs, such as change the page layout, add task flows, documents, and other objects to a page, or wire pages to each other.
Using the Personalization menu: The Personalization menu in the global area of Oracle Fusion Applications gives an end user access to Page Composer to customize a page to suit their needs. Only the end user sees the changes. End users can also use the Personalization menu to reset a page to display the default content and layout.
Using the Customization Manager: Customization Manager enables end users who have the correct permissions, such as administrators, to download, upload, reset, and delete application customizations on objects such as pages and task flows.
Some customizations, such as changes to the model or to task flow roles, must be done from Oracle JDeveloper, as described in the "Using Oracle JDeveloper for Customizations" chapter in the Extensibility Guide for Developers. Customizations made from JDeveloper are referred to as design-time customizations. Design-time customizations that are created and shipped with Oracle Fusion Applications are known as seeded customizations.
Note:
End users with the correct permissions can also customize some menus, such as the navigator menu.
For more information about customization, see the "Customizing and Extending Oracle Fusion Applications" chapter in the Extensibility Guide for Developers.
A customized application contains a base application and one or more layers of customized metadata content. The customized metadata objects are stored in an MDS repository and, when a customized application is launched, the customized content is retrieved and applied over the base content.
Note:
When you run your page in JDeveloper, all customizations created at runtime are, by default, written to a simulated MDS repository directory, which is stored at a temporary location in your system directory. The simulated MDS repository that is configured for the application reflects the metadata information that is contained in the Metadata Archive (MAR).
For more information, see Section 55.2.1, "How to Deploy an Application with Metadata to Integrated WebLogic Server."
To enable runtime customizations of an application, you first prepare the application for customizations, then you enable the runtime customization of pages and components.
To enable an application for customization, you must complete the following steps in your JDeveloper application workspace in the order shown.
After you complete these steps, you can enable runtime customization for the application's web pages and task flows as described in Enabling Runtime Customization of Pages and Components.
To enable user customizations, you must configure the view project to persist the customized metadata objects to an Oracle Metadata Services (MDS) repository so that the objects are available across sessions. You must also enable seeded customizations so that the page fragments and JSPX pages that you create will be configured to allow customizations.
Note:
ADF components (such as controller, model, and business components objects) must have a unique identifier so that they can be customized. ADF components that are generated by JDeveloper are created with identifiers by default, except for fragments and pages in your user interface projects. To cause JDeveloper to generate identifiers for components on pages that you create in your user interface projects, you must explicitly specify this at the project level by enabling seeded customizations.
To set project properties for your view project:
You must configure the persistence change manager to cause the following runtime behavior to occur:
The Persist and Don't Persist attributes that you set for components at design time will govern which implicit changes that the end users make at runtime will be persisted during the session as well as across sessions.
The changes that end users make in the design view of Page Composer will be stored in the MDS repository.
When you enabled user customizations across sessions by completing the procedure in How to Set Project Properties to Enable User and Seeded Customizations, the IDE added the CHANGE_PERSISTENCE
context parameter to the view project's web.xml
file, and set the parameter to use the filtered persistence change manager. You must modify this parameter to use the composer change manager, and you must add the composer filter and its mapping.
Before you begin:
Modify your view project's properties to enable user customizations across sessions as described in How to Set Project Properties to Enable User and Seeded Customizations.
To configure the persistence change manager:
In the Application Navigator, expand the WEB-INF node for your view project and double-click web.xml.
In the source editor, change the org.apache.myfaces.trinidad.CHANGE_PERSISTENCE
context parameter value to oracle.adf.view.page.editor.change.ComposerChangeManager
, as shown in the following code.
<context-param>
<param-name>org.apache.myfaces.trinidad.CHANGE_PERSISTENCE</param-name>
<param-value>
oracle.adf.view.page.editor.change.ComposerChangeManager
</param-value>
</context-param>
Add the filter and filter-mapping elements for the WebCenterComposerFilter
class as shown in bold in Example 64-1.
Note:
Filters must be configured in the following order.
JpsFilter
ApplSessionFilter
WebCenterComposerFilter
ADFBindingFilter
Enable sessions for the JSPX pages and task flows that you create in your view project as described in How to Configure Your Project to Use Application User Sessions.
This step, among other modifications, adds the Applications Core and Web Service Data Control libraries to your project, which you need to complete the tasks to prepare your application for customization.
Example 64-1 composerFilter and Mappings in web.xml
.... <!-- composerFilter goes here --> <filter> <filter-name>composerFilter</filter-name> <filter-class> oracle.adf.view.page.editor.webapp.WebCenterComposerFilter </filter-class> </filter> <filter> <filter-name>adfBindings</filter-name> <filter-class>oracle.adf.model.servlet.ADFBindingFilter</filter-class> </filter> ..... <!-- composerFilter mapping goes here --> <filter-mapping> <filter-name>composerFilter</filter-name> <servlet-name>Faces Servlet</servlet-name> <dispatcher>FORWARD</dispatcher> <dispatcher>REQUEST</dispatcher> </filter-mapping> <filter-mapping> <filter-name>adfBindings</filter-name> <servlet-name>Faces Servlet</servlet-name> <dispatcher>FORWARD</dispatcher> <dispatcher>REQUEST</dispatcher> </filter-mapping> ....
You must configure your application to enable end users to provide translated values for customized strings at runtime, as described in the "Translating Custom Text" chapter in the Extensibility Guide for Developers.
The resource string editor enables the runtime editing of strings. The changes made using the resource string editor are saved into an application override bundle, which can be translated and imported back into the application.
For more information about configuring the runtime resource string editor, see the "Configuring Runtime Resource String Editing" section in the Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.
Note:
This procedure only enables resource string editing if the changes are customizations and not user personalizations, as user personalizations do not need to be translated.
To set up runtime resource string editing for customizations:
Example 64-2 Configuration to Turn On Resource Editor
<pe:page-editor-config> ... <resource-string-editor> <enabled> #{GlobalAreaBackingBean.tipLayerNonUser} </enabled> </resource-string-editor> </pe:page-editor-config>
You must add the Oracle WebCenter Portal — Composer technology scope to access the technologies for consuming Page Composer components and enabling runtime customization.
To add Composer technology scope:
You can configure the UI Shell template so that it can be customizable out-of-the-box. This functionality enables customers to use Page Composer to customize UI Shell pages.
To enable users to customize the UI shell template, you add a link or button to the page fragment from which you want end users to launch the UI Shell template for editing. You then configure the link (or button) to enable end users to modify the template.
To enable the user customization of the UI Shell Template:
Example 64-3 Sample custClass List
oracle.apps.fnd.applcore.customization.GlobalCC,oracle.apps.fnd.applcore.customization.SiteCC
Example 64-4 custNavigate methodAction Binding
<bindings> <methodAction id="custNavigate" RequiresUpdateModel="true" Action="invokeMethod" MethodName="navigate" IsViewObjectMethod="false" DataControl="FndUIShellController" InstanceName="FndUIShellController.dataProvider" ReturnName= "FndUIShellController.methodResults.navigate_FndUIShellController_dataProvider_navigate_result"> <NamedData NDName="viewId" NDValue="TemplateCustomizationUIShell" NDType="java.lang.String"/> <NamedData NDName="webApp" NDType="java.lang.String"/> <NamedData NDName="pageParametersList" NDType="java.lang.String"/> <NamedData NDName="navTaskFlowId" NDType="java.lang.String"/> <NamedData NDName="navTaskKeyList" NDType="java.lang.String"/> <NamedData NDName="navTaskParametersList" NDType="java.lang.String"/> <NamedData NDName="navTaskLabel" NDType="java.lang.String"/> <NamedData NDName="methodParameters" NDType="oracle.apps.fnd.applcore.patterns.uishell.ui.bean.FndMethodParameters"/> </methodAction> </bindings>
In addition to the application level connection to your application database, you might also need to create an Integrated Development Environment (IDE) connection.
The IDE connection is required when implementing design-time customizations from JDeveloper, as described in the "Using Oracle JDeveloper for Customizations" chapter in the Extensibility Guide for Developers.
To create a database connection at the IDE level
After you have completed the non-optional procedures described in Preparing an Application for Customizations, you can enable pages, task flows, and components for runtime customization.
To enable an application's pages, task flows, and components for runtime customization:
As shown in Figure 64-3, the settings that you make by following the procedures in this section affect whether an end user can customize an object under the following scenarios.
Note:
For simplicity, the Page Composer scenarios assume that the settings for the page are set to enable the editing of components. For more information, see How to Control the Editing of Components in .
User performs an implicit customizations: If the component can be persisted and customization is allowed, the implicit customization is persisted for the session as well as across sessions.
User accesses Customization Manager: If the end user has an administrative role or privilege, the user can access the Customization Manager. If the task flow has edit permissions for a user's role or privilege, the user can import, export, or delete customizations of objects for which customization is allowed.
User accesses Page Composer to customize a page: If the end user has an administrative role or privilege and customization is allowed for the page (JSPX root), the user can access Page Composer. If the task flow has edit permissions for the user's role or privilege, the user can customize any object for which customization is allowed.
User accesses Page Composer to personalize a page: If the page enabled for end-user personalizations and customization is allowed for the page (JSPX root), the user can access the page in Page Composer. If the task flow has edit permissions for the user's role or privilege, the user can customize any object for which customization is allowed.
User accesses Page Composer to reset content and layout: If customization is allowed for the page and the task flow has edit permissions for the user's role or privilege, the user can reset the content and layout for which customization is allowed.
To determine whether customization is allowed, the application looks at the component's Customization Allowed property to see if it has an explicit value. If there is no explicit value, the application looks at the parent object and continues up the tree, ending at the JSF page fragment (.jsff
root), until it finds an explicit value. For example, if Customization Allowed is not set for a component, but is set to true
for the page fragment, then customization is allowed for the component. However, if Customization Allowed is false
for the component, the application disallows customization of that object, even if the page fragment's Customization Allowed property is set to true
. Conversely, if the page fragment's Customization Allowed property is set to false
, but a component's property is set to true
, the end user can customize the component.
By default the Customization Allowed property for the page (.jspx
) root is true. Therefore, you must explicitly set Customization Allowed to false
at some level, such as for a component, region, or page (.jspx
), to disallow customization for that object and its child objects. A fragment (.jsff
) is loaded by MDS as a separate document and does not inherit the Customization Allowed property from the containing page (.jspx
).
Note:
You can optionally use the Customization Allowed By property to permit customizations only for certain roles.
Figure 64-3 Runtime Effects of Customization Settings
Perform the following steps to enable runtime customization of a web page using Page Composer:
Page definition files define the binding objects that populate data the data in UI components at runtime. A page definition is required for runtime customizations that add additional components such as task flows and portlets. Page definition files can be found under Projects > View Controller > Application Sources > oracle.apps.view. If a required page definition file does not exist, complete the following steps to create one.
To create a page definition file for a JSPX page:
To make a JSPX document editable at runtime, you add Composer components to the page at design time. You use the Panel Customizable component to define an area of the page onto which users can add components at runtime. You use the Layout Customizable component to enable users to lay out its child components in several predefined ways, such as two-column or three-column.
The Layout Customizable and Panel Customizable components are from the Oracle WebCenter Portal — Composer technology scope, which you added when you completed the steps in How to Add Technology Scope to Your Project, and which are available from the Composer page in the Component Palette.
For more information about the Panel Customizable and Layout Customizable components, see the Composer Components section in the Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.
If you have a Panel Customizable component on your page to enable the runtime addition of content, you must set up a resource catalog to list the available content.
To learn how to create a custom resource catalog, see the Creating and Managing Resource Catalogs chapter in the Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.
A considerable amount of work is involved in setting up a resource catalog. If you want to test runtime customizations before you finish setting up your catalog, you can use the default catalog definition file.
To use the default catalog for testing:
/ViewController/src/oracle/adf/rc/metadata
directory structure.default-catalog.xml
to the newly created application_root/ViewController/src/oracle/adf/rc/metadata
directory.Caution:
The Oracle WebCenter Portal default catalog should only be used for testing purposes. You must create your own catalog for production purposes.
Control whether an end user can personalize a page by setting the page's isPersonalizableInComposer
property.
Note:
You must enable personalizations for all your dashboards. However, workareas should have personalizations enabled only if absolutely required.
To enable end-user personalizations:
.jspx
page.Customization is enabled for pages, page fragments, and components by default. However, there might be situations where you want to prevent customization for some objects.
You can specify at the page, page fragment, or component level whether customizations for a component are permitted at runtime and who is permitted to customize that component.
Before you begin:
Review the introduction to Enabling Runtime Customization of Pages and Components to understand how the application uses the value of the Customization Allowed property to determine whether an object can be customized.
To restrict customization of a page, page fragment, or component:
For more information about these attributes, see the Extended Metadata Properties section in the Developing Fusion Web Applications with Oracle Application Development Framework.
For information about customization layers, see the Understanding Customization Layers section in the Extensibility Guide for Developers.
As described in How to Restrict Customization of a Page_ Page Fragment_ or Component , all end users who can personalize or customize a page can use Page Composer to change the layout on a page by default.
For some pages, Page Composer enables end users to configure a page in either Source view or Design view. For other pages, end users can only configure the page in Design view. By default, end users can add and edit components in Source view. In Design view the default is to allow end users to add components to a page but not edit existing components. You can configure the page to allow users to select components for editing in Design view, as shown in Figure 64-4, or you can configure the page to disallow both adding and editing components.
Figure 64-4 Page Configured to Allow Users to Add and Edit Components
If a page has properties with EL expressions that you do not want changed, you can set all existing property EL expressions to read-only. For example, the page in Figure 64-4 was configured to disallow the editing of existing EL expressions and, therefore, the user cannot edit the Action Listener property. In addition, you can configure a page to disallow entering new EL expressions. That is, you can prevent users from entering EL expressions in property fields that do not currently contain EL expressions.
Figure 64-5 Page Configured to Not Allow Editing of Existing EL Expressions
Table 64-1 lists the properties that you set at the af:pageTemplate
level to control the editing of components in Page Composer.
Table 64-1 af:pageTemplate Properties for Page Composer
Property | Type | Supports EL | Description |
---|---|---|---|
allowELInComposer |
|
No |
Specifies if EL expressions can be entered for form element properties. The default value is |
designViewsInComposer |
|
No |
Specifies the views available to the user in Page Composer Design view. This property can take a space-separated list of elements. The following options are available:
|
protectELInComposer |
|
No |
Specifies if existing EL expressions in the page's form elements are read-only. The default value is |
Table 64-2 lists all possible combinations of allowELInComposer and protectELInComposer property values and describes how each combination affects the user's ability to add and edit EL expressions.
Table 64-2 Affects of allowELInComposer and protectELInComposer Property Settings
Combination | Affect |
---|---|
protectELInComposer = |
Users can add an EL expression to a property if it does not currently have an EL expression and if EL expressions are allowed for that property. However, users cannot edit existing EL expressions. |
protectELInComposer = |
Users can add and edit EL expressions in properties for which EL expressions are allowed |
protectELInComposer = |
Users cannot add an EL expression to a property if it does not currently contain an EL expression, but they can edit existing EL expressions. |
protectELInComposer = |
User cannot add or edit EL expressions. |
As illustrated in Figure 64-3 a user can edit customizable components in a user interface page at runtime only if they have permission to edit the page and permission to edit the task flow that contains the component. For example, an end user can only customize components in a task flow using Page Composer if that user has permission to customize the task flow. You use the jazn-data.xml
file to define which roles can edit the page or task flow.
Before you begin:
Enable the desired pages for editing in Page Composer as described in Enabling Runtime Customization of Pages and Components.
To authorize pages and task flows for runtime customizations:
For more information, see the Implementing Task Flow Security section in the Developing WebCenter Portal Assets and Custom Components with Oracle JDeveloper.
Certain ADF Faces components have attributes that can be saved during a user session. For example, if a user expands a panel box component, the box will be expanded when the user returns to the page. This type of change is referred to as implicit runtime customization. For information about which component properties can be persisted, see the Allowing User Customizations at Runtime chapter in the Developing Fusion Web Applications with Oracle Application Development Framework.
In How to Set Project Properties to Enable User and Seeded Customizations, you configured the application to persist implicit runtime customizations across sessions as well as within sessions.
The attributes that can be persisted are set in the tag library, but you can override these settings. For example, you might not want the end users to change column widths, but you want all other default attribute changes for columns to be persisted. You set and unset these values in the Overview Editor for the adf-config.xml
file, as described in the Configuring User Customizations section in the Developing Fusion Web Applications with Oracle Application Development Framework. You can also override these settings for specific components, as described in the Controlling User Customizations in Individual JSF Pages section in the Developing Fusion Web Applications with Oracle Application Development Framework.