This chapter includes the following sections:
JDeveloper offers extensive support for refactoring Fusion web application components, available through the Refactor main menu selections or via context menus for selected ADF components. The refactoring of ADF application components in most cases includes renaming, moving, and deleting these components.
JDeveloper provides refactoring options that allow you to make changes to the name and location of attributes, named elements, files, and ADF Business Components objects that your application uses. These refactoring options synchronize your changes with other parts of the application that are dependent on the changes. For example, renaming an ADF Business Components object such as a view object using the Rename option renames any references to it in other XML source files.
In a Fusion Web Application, you can use the refactoring actions (move, rename, and delete) in JDeveloper to make changes to the names and locations of objects. These actions are available from the main menu under Refactor, as well as the context menu for each type of object in the Applications window. The move, rename, and delete operations are available for most (but not all) objects and file types. When an object or file is selected in the Applications window, the applicable refactoring operations are enabled in the Refactor menu.
Additionally, there are limitations to what you can refactor in JDeveloper. In some cases, such as moving a project configuration file, there are manual procedures that you can follow. For more information, see Refactoring Limitations .
During the course of development, you will create objects such as entity objects, as needed, to satisfy the needs of the application. Then you might find that you need to subsequently need to delete an object that is no longer used, rename an object to fit a naming convention, or move a set of objects into a different package to consolidate their location. Using JDeveloper, you can refactor these objects so that they are updated and the references to these objects in other objects are also updated to maintain the integrity of the whole application.
You may find it helpful to understand other refactoring features available from JDeveloper. Following are links to other functionality that may be of interest.
For additional information about using JDeveloper features for refactoring Java code, see the Refactoring Java Projects section of Developing Applications with Oracle JDeveloper.
You can display the Refactor menu when you right-click on the ADF Business Component in the Applications window. If you choose to rename a component, JDeveloper will present a Rename dialog. In this dialog you can specify the new name for the object and choose to preview the changes that will be generated by the refactoring process.
You can rename files, such as configuration files, using the following methods:
In the Applications window, select the file and choose File > Rename from the main menu.
In the Applications window, right-click the file and choose Refactor > Rename.
In the source editor, select a class name, right-click it, and choose Rename.
To move a file between directories, use the Move menu item.
When you rename or move a file, all references to the file are updated as well. For example when you rename a page definition file, its entry in the DataBindings.cpx
file is updated accordingly.
You cannot rename the XML file or Java files associated with an ADF Business Components object independently of the object, as these files must be kept in synch. See Refactoring ADF Business Components .
You can change the package of the JSF page with the Refactor menu. This updates the faces-config.xml file, DataBindings.cpx mappings to the page, and the ADF task flows containing page views.
In addition to the other refactoring operations, you can change the package of a JSF page. In the Applications window, right-click a JSF page and choose Refactor > Move to move the page to another package. Moving the JSF page to another package updates:
faces-config.xml
files that reference the page and its package
ADF task flows containing views associated with the page
DataBindings.cpx
mappings to the page
The pagedef.xml file defines bindings and executables that populate the data in UI components at runtime. You can choose any data binding or executable and rename or delete it using the Refactor menu.
The pagedef.xml
binding objects that you can refactor include bindings and executables. See Working with Page Definition Files.
Before you begin:
It may be helpful to have an understanding of the options you have for refactoring. See About Refactoring a Fusion Web Application .
In JDeveloper, open the application that contains the objects you want to refactor.
To refactor pagedef.xml binding objects:
When it comes to refactoring ADF components in JDeveloper, the common refactoring features that are used are rename, move or delete ADF Business Components objects.
ADF Business Components includes objects such as view objects and entity objects. Table 49-1 shows support for refactoring ADF Business Components.
Table 49-1 Refactoring ADF Business Components
Action | Result |
---|---|
Move |
Moves the object to a different package or directory and updates all references. |
Delete |
JDeveloper shows all dependencies on the object and permits a forced delete. The application may not work at this point. You may need to resolve broken references. |
Rename |
ADF Business Components objects are defined by an XML file. The XML file has a file name identical to the object name. For example, the name of the XML file for a view object named For example, the name of an entity ( |
Find Usages |
JDeveloper shows all dependencies on the object. |
Note:
Refactoring does not cross abstraction layers. For example, when a view object is created based on the Dept
entity object, it is named DeptView
by default. Renaming the Dept
entity object updates the entity usage in DeptView
, but does not change the name of the view object.
Before you begin:
It may be helpful to have an understanding of the options you have for refactoring. For more information, see About Refactoring a Fusion Web Application .
In JDeveloper, open the application that contains the object you want to refactor.
To refactor ADF Business Components objects:
You can refactor attributes of ADF Business Components entity objects and view objects.
Table 49-1 shows support for refactoring attributes of ADF Business Component entity objects and view objects.
Table 49-2 Refactoring Attributes
Action | Result |
---|---|
Move |
Not supported. |
Delete |
JDeveloper shows all dependencies on the attribute and permits a forced delete. The application may not work at this point. You may need to resolve broken references. |
Rename |
Attributes share data elements represented in entity and view objects (see About Entity Objects for more information). References to the attribute are updated when you rename the attribute. Renaming results in changing the Renaming an attribute does not change the data it represents, nor does it rename the underlying table column. |
Find Usages |
JDeveloper shows all dependencies on the attribute. |
Before you begin:
It may be helpful to have an understanding of the options you have for refactoring. See About Refactoring a Fusion Web Application .
In JDeveloper, open the application that contains the attribute you want to refactor.
To refactor attributes:
A named element is not an object or attribute. Named elements are elements in the XML schema that can be referenced by a Name attribute. JDeveloper allows you to refactor a named element.
Named elements are any elements in the XML schema that can be referenced by a Name
attribute. A named element is not an object or an attribute. Table 49-3 shows support for refactoring named elements in an XML schema.
Table 49-3 Refactoring Named Elements
Action | Result |
---|---|
Move |
Not supported. |
Delete |
Not supported. |
Rename |
One exception to the definition of named elements is the design time element |
Find Usages |
JDeveloper shows all dependencies on the named element. |
Before you begin:
It may be helpful to have an understanding of the options you have for refactoring. See About Refactoring a Fusion Web Application.
In JDeveloper, open the application that contains the named element you want to refactor.
To refactor named elements:
You can refactor existing activities, JSF page flows, and JSF pages into new ADF Controller components such as bounded task flows and task flow templates using JDeveloper.
For more information, see Refactoring to Create New Task Flows and Task Flow Templates.
In order to rename or move the DataBindings.cpx file, you need to create the new one and delete the existing one. While doing this you must not forget to update the adfm.xml file which is the registry of registries and the id property must be similar to the DataBindings.cpx file name otherwise you will get an error message.
The DataBindings.cpx
file defines the Oracle ADF binding context for the entire application and provides the metadata from which the Oracle ADF binding objects are created at runtime (see DataBindings.cpx Syntax for more information). This file is a registry used to quickly find all .cpx
, .dcx
, .jpx
, and .xcfg
files, which are themselves registries of metadata.
If you rename the DataBindings.cpx
file to a new name, such as DataBindingsNew.cpx
, the change is added to the adfm.xml
file.
The following example shows the contents of the adfm.xml
file after DataBindings.cpx
is refactored to DataBindingsNew.cpx
.
<?xml version="1.0" encoding="UTF-8" ?> <MetadataDirectory xmlns="http://xmlns.oracle.com/adfm/metainf" version="11.1.1.0.0"> <DataBindingRegistry path="adf/sample/view/DataBindingsNew.cpx"/> </MetadataDirectory>
Additionally, to enable the application to access the correct bindings file, the ID value is changed to an ID similar to the one shown in the following example.
<Application xmlns="http://xmlns.oracle.com/adfm/application" version="11.1.1.49.28" id="DataBindingsNew" SeparateXMLFiles="false" Package="adf.sample.view" ClientType="Generic">
JDeveloper has set of refactoring issues and limitations that are listed here.
Table 49-4 summarizes the limitations of JDeveloper's refactoring support.
Table 49-4 Refactoring Limitations
Area | Limitation |
---|---|
Database |
When a database artifact used in an ADF Business Components object is renamed, the object needs to be updated. This type of refactoring is currently not supported. |
Service interface |
A service interface defines a contract between two separate pieces of software. For example, the ADF Business Components service interface is responsible for exposing business components to the view and model layers. Changing the name of a service interface can cause a conflict. While developing the application, consider removing the service interface, refactoring the object, and regenerating the service interface. Additionally, if your service interface defines a find operation based on a view criteria that specifies bind variables, changing the number or order of the bind variables in the underlying view criteria will require that you regenerate the service interface. |
Java literal references |
The Java code generated by ADF Business Components has literal references to the XML metadata. These literal references are updated during refactoring operations. Generated (type safe) methods are also updated. Also, the refactor delete operation is available for local Java variables. However, if the application code directly refers to the metadata, these references are not updated. |
Domain |
If a domain needs to be renamed or moved, you must create the new domain, then change the type of existing domain usages.For example, you might rename a domain called |
Security |
Security policies in the policy store may reference the name of an entity object, attribute, page, or task flow. These policy definitions are not updated in response to the refactoring of the object itself. |
Resource Bundles |
Entity object definitions can reference a resource in one or more arbitrary resource bundle ( |
|
Renaming the ADF Business Components project configuration file ( In previous versions of JDeveloper, ADF Business Components project configuration |
If the ADF Business Components Project file (.jpx) is moved to a different package, then the jbo.project property available in bc4j.xcfg file must be changed accordingly. However, it is not always changed automatically.
Although refactoring the ADF Business Components project configuration file (.jpx
) is not supported, you may need to change its name or location to avoid conflicts when sharing your project contents as an ADF library. The .jpx
file contains configuration information that JDeveloper uses in the design time to allow you to create the data model project with ADF Business Components. If you need to refactor this file, you must do so manually.
Before you begin:
It may be helpful to have an understanding of the options you have for refactoring. See About Refactoring a Fusion Web Application.
To manually move the ADF Business Components project configuration file (.jpx):