Oracle® Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework 11g Release 1 (11.1.1.7.2) Part Number B31974-15 |
|
|
PDF · Mobi · ePub |
This chapter describes considerations for renaming, moving, and deleting files, configuration files, objects, attributes, and elements in a Fusion web application. In most cases, JDeveloper automatically performs refactoring. However, you may need to complete some manual steps to refactor.
This chapter includes the following sections:
Section 32.1, "Introduction to Refactoring a Fusion Web Application"
Section 32.6, "Refactoring ADF Business Component Object Attributes"
JDeveloper provides refactoring options to rename, move, and delete the ADF Business Components objects, attributes, and named elements 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 using the Rename option renames any references to it in other XML source files.
You can rename files such as configuration files using the following methods:
In the Application Navigator, select the file and choose File > Rename from the main menu.
In the Application Navigator, right-click the file and choose Refactor > Rename.
In the source editor, select a class name, right-click it, and choose Rename.
In the Application Navigator, you can right-click a JSF page and choose Refactor > Move to Package 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
binding objects that you can refactor include bindings and executables. For more information, see Section 12.6, "Working with Page Definition Files."
To refactor pagedef.xml binding objects:
In the Application Navigator, select the page node on which you have added a bound object such as an ADF Form or selection list.
Right-click the page node and choose Go to Page Definition.
If the page does not already have a page definition, the Create Page Definition dialog displays. Click OK to create a page definition for the page.
In the overview editor, expand the Model section.
Data bindings such as list bindings and iterator bindings defined for the page display under Bindings and Executables, as shown in Figure 32-1.
Right-click a data binding or executable, choose Refactor and a refactoring option such as Rename or Delete.
To display the usages between bindings, executables, and data controls, right-click a binding or executable and choose Find Usages.
ADF Business Components includes objects such as view objects and entity objects. Table 32-1 shows support for refactoring ADF Business Components.
Table 32-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. |
To refactor ADF Business Components objects:
In the Application Navigator, expand the Projects node containing the object you want to refactor.
Within the project, expand the Application Sources node and then the package containing the object you want to refactor.
Right-click the object and choose Refactor > Rename or Refactor > Move.
To delete the object, choose Delete.
If the object is used elsewhere in the application, a dialog displays with the following options:
Ignore: Unresolved usages will remain in the code as undefined references.
View Usages: Display a preview of the usages of the element in the Compiler log. You can use the log to inspect and resolve the remaining usages.
Table 32-1 shows support for refactoring attributes of ADF Business Component entity objects and view objects.
Table 32-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 Section 4.1, "Introduction to 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. |
To refactor attributes:
In the Application Navigator, expand the Projects node containing the object you want to refactor.
Within the project, expand the Application Sources node and then the package containing the object you want to refactor.
Double-click the object.
In the overview editor, select Attributes.
In the Name column, select an attribute.
Right-click and choose Rename or Delete.
To delete the attribute, choose Delete.
If the attribute is used elsewhere in the application, a dialog displays with the following options:
Ignore: Unresolved usages will remain in the code as undefined references.
View Usages: Display a preview of the usages of the attribute in the Compiler log. You can use the log to inspect and resolve the remaining usages.
Table 32-3 shows support for refactoring named elements in an XML schema. 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 32-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. |
To refactor named elements:
In the Application Navigator, expand the Projects node containing the object you want to refactor.
Within the project, expand the Application Sources node and then the package containing the object you want to refactor.
Double-click the object.
In the overview editor, click the Source tab.
Scroll down to a named element.
Named elements are indicated by Name="<element>"
in the source code, for example:
<Key Name="PersonsAffContactChk">
A named element is not an object or attribute.
To rename the element, right-click the element and choose Rename.
To delete the element, choose Delete.
If the element is used elsewhere in the application, a dialog displays with the following options:
Ignore: Unresolved usages will remain in the code as undefined references.
View Usages: Display a preview of the usages of the element in the Compiler log. You can use the log to inspect and resolve the remaining usages.
For more information, see Section 14.5, "Refactoring to Create New ADF Task Flows and Templates."
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 Section A.7.1, "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.
Example 32-1 shows the contents of the adfm.xml
file after DataBindings.cpx
is refactored to DataBindingsNew.cpx
.
Example 32-1 Renamed DataBindings.cpx file in adfm.xml
<?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>
After this change, the application won't run because the data control cannot be found. Example 32-2 shows the old ID in the DataBindingsNew.cpx
file. To enable the application to access the correct bindings file, update the ID value in the DataBindingsNew.cpx
file to the new file.
Example 32-2 DataBindingsNew.cpx ID
<Application xmlns="http://xmlns.oracle.com/adfm/application" version="11.1.1.49.28" id="DataBinding" SeparateXMLFiles="false" Package="adf.sample.view" ClientType="Generic">
This should be changed to an ID similar to the one shown in Example 32-3.
Refactoring does not cross abstraction layers. For example, when a view object is created based on the entity Dept
, it is named DeptView
by default. Renaming Dept
updates the entity usage in DeptView
, but does not change the name of the view object.
Table 32-4 summarizes the limitations of JDeveloper's refactoring support.
Table 32-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. For more information, see Chapter 11, "Integrating Service-Enabled Application Modules." |
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. However, if the application 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 |
Entity object and attribute security policies in the policy store may reference the name of an entity object or attribute. These policy definitions are not updated in response to the refactoring of an entity object or attribute. |
Resource Bundles |
Entity object definitions can reference a resource in one or more arbitrary resource bundle ( |
|
Renaming the ADF Business Components ( In previous versions of JDeveloper, ADF Business Components |
JDeveloper supports refactoring ADF Business Components.
To manually move the .jpx project file:
Move the.jpx
file to the new source tree location.
For example, you can move the Model.jpx
file from src/Model.jpx
to src/packagenames/go/here/Model.jpx
.
Change the .jpx
file contents. The PackageName
attribute of the root element JboProject
needs to have the correct value.
For example, you can specify PackageName="packagenames.go.here"
.
Change the jbo.project
attributes in all common/bc4j.xcfg
files that contain elements referred to in the.jpx
file to include the new package name.
For example:
<AppModuleConfig name="ScottDeptAMLocal" ApplicationName="packagenames.go.here.ScottDeptAM" DeployPlatform="LOCAL" JDBCName="scottdb" jbo.project="packagenames.go.here.Model">
Change the JDeveloper project file (the.jpr
file) contents:
Set the new.jpx
package location. If you later change the default package in the project properties, you will again raise a NotFound
error for the.jpx
file.
For example:
<value n="defaultPackage" v="packagenames.go.here"/>
Fix any ownerURL
elements in the ownerMap
that contain references to the old location of the.jpx
file.
For example:
<url n="ownerURL" path="src/packagenames/go/here/Model.jpx"/>