Fusion Middleware Documentation
Advanced Search


Developing Fusion Web Applications with Oracle Application Development Framework
Close Window

Table of Contents

Show All | Collapse

43 Refactoring a Fusion Web Application

This chapter describes considerations for renaming, moving, and deleting source files, configuration files, objects, attributes, and elements in a Fusion web application. In most cases, JDeveloper can perform the complete refactoring. However, in some cases, you might need to complete some manual steps to refactor.

This chapter includes the following sections:

43.1 About Refactoring a Fusion Web Application

JDeveloper provides refactoring options that allow you to make changes to the name and location 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.

43.1.1 Refactoring Use Cases and Examples

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.

43.1.2 Additional Functionality for Refactoring

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.

43.2 Renaming Files

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. For more information, see Section 43.5, "Refactoring ADF Business Components."

43.3 Moving JSF Pages

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

43.4 Refactoring pagedef.xml Bindings Objects

The pagedef.xml binding objects that you can refactor include bindings and executables. For more information, see Section 17.7, "Working with Page Definition Files."

Before you begin:

It may be helpful to have an understanding of the options you have for refactoring. For more information, see Section 43.1, "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:

  1. In the Applications window, select the page node on which you have added a bound object such as an ADF Form or selection list.

  2. 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 appears. Click OK to create a page definition for the page.

  3. In the overview editor, click the Bindings and Executables tab.

    Data bindings such as list bindings and iterator bindings defined for the page display under Bindings and Executables, as shown in Figure 43-1.

    Figure 43-1 Page Data Binding Definition Overview Tab

    Page Data Binding Definition
  4. In the Structure window, right-click a data binding or executable, choose Refactor and a refactoring option, such as Rename or Delete.

  5. To display the usages between bindings, executables, and data controls, right-click a binding or executable and choose Find Usages.

43.5 Refactoring ADF Business Components

ADF Business Components includes objects such as view objects and entity objects. Table 43-1 shows support for refactoring ADF Business Components.

Table 43-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 Persons1View is Persons1View.xml. Renaming results in changing the Name attribute, renaming the XML file, and updating all references.

For example, the name of an entity (Customer) is stored as an attribute in the XML file (name=Customer). The XML file has the same name the entity name (Customer.xml).

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 Section 43.1, "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:

  1. In the Applications window, expand the project and then the Application Sources node and then the package containing the object you want to refactor.

  2. Right-click the object and choose Refactor and a refactoring option.

    • To change the name of the object, choose Rename.

      The Rename dialog displays the current name of the object. Enter the new object name and click OK to proceed with the refactoring or Cancel to cancel.

      You can optionally select Preview and click OK to display the usages in the Log window, which allows you to proceed with the refactoring or cancel. When you click a usage in the Log window, the file that contains the usage is opened in the Source editor and the containing line is highlighted.

    • To change the location of the object, choose Move.

      The Move dialog displays the current location of the object. Enter the new package name, or click Browse to navigate to it. Click OK to proceed with the refactoring or Cancel to cancel.

    • To remove the object, choose Delete.

      The Confirm Delete dialog displays the name of the object and searches for usages. Click Show Usages to display where the object is used. Click Yes to proceed with the refactoring or No to cancel. Click Preview to display the results in the Log window, which allows you to proceed with the refactoring or cancel. When you click a usage in the Log window, the file that contains the usage is opened in the Source editor and the containing line is highlighted.

      By default JDeveloper searches in the current application for usages of the object. You can change the scope of the search by choosing from the Finding Usages In dropdown list, or by clicking the Manage Working Sets icon.

43.6 Refactoring ADF Business Component Object Attributes

Table 43-1 shows support for refactoring attributes of ADF Business Component entity objects and view objects.

Table 43-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, "About Entity Objects" for more information). References to the attribute are updated when you rename the attribute. Renaming results in changing the Name attribute and updating all references. This includes updating the service implementation of view attributes used in an application module's generated service.

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. For more information, see Section 43.1, "About Refactoring a Fusion Web Application."

In JDeveloper, open the application that contains the attribute you want to refactor.

To refactor attributes:

  1. In the Applications window, double-click the entity object or view object that contains the attribute you want to refactor.

  2. In the overview editor, click the Attributes navigation tab.

  3. In the Name column, right-click the attribute and choose a refactoring option.

    • To change the name of the attribute, choose Rename.

      The Rename dialog displays the current name of the attribute. Enter the new attribute name and click OK to proceed with the refactoring or Cancel to cancel.

      You can optionally select Preview and click OK to display the usages in the Log window, which allows you to proceed with the refactoring or cancel.

    • To see where the attribute is used, choose Find Usages.

      The Log window displays usages of the attribute. When you click a usage in the Log window, the file that contains the usage is opened in the Source editor and the containing line is highlighted.

    • To remove the attribute, choose Delete.

      In the Confirm Delete dialog, click Show Usages to display where the attribute is used. Click Yes to proceed with the refactoring or No to cancel. Click Preview to display the results in the Log window, which allows you to proceed with the refactoring or cancel.

    • To change the type of the attribute, choose Change Type.

      In the Change Type dialog, choose the new type from the Type dropdown list, or click Browse to find the type. Click OK to proceed with the refactoring or Cancel to cancel.

      You can optionally select Preview and click OK to display the usages in the Log window, which allows you to proceed with the refactoring or cancel.

43.7 Refactoring Named Elements

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 43-3 shows support for refactoring named elements in an XML schema.

Table 43-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 Attr, which does have a Name attribute. Attr is a name-value pair, is not accessible from the code editor, and should not be renamed.

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. For more information, see Section 43.1, "About Refactoring a Fusion Web Application."

In JDeveloper, open the application that contains the named element you want to refactor.

To refactor named elements:

  1. In the Applications window, double-click the entity object or view object that contains the named element you want to refactor.

  2. In the editor window, click the Source tab, and search or scroll to find the 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.

  3. Right-click the named element you want to refactor and choose Refactor and a refactoring option.

    • To change the name of the element, choose Rename.

      The Rename dialog displays the current name of the element. Enter the new element name and click OK to proceed with the refactoring or Cancel to cancel.

      You can optionally select Preview and click OK to display the usages in the Log window, which allows you to proceed with the refactoring or cancel.

    • To remove the element, choose Delete.

      In the Confirm Delete dialog, click Show Usages to display where the element is used. Click Yes to proceed with the refactoring or No to cancel. Click Preview to display the results in the Log window, which allows you to proceed with the refactoring or cancel.

43.8 Refactoring ADF Task Flows

For more information, see Section 20.6, "Refactoring to Create New Task Flows and Task Flow Templates."

43.9 Refactoring the DataBindings.cpx File

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 43-1 shows the contents of the adfm.xml file after DataBindings.cpx is refactored to DataBindingsNew.cpx.

Example 43-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> 

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 Example 43-2.

Example 43-2 Updated DataBindingsNew.cpx ID

<Application xmlns="http://xmlns.oracle.com/adfm/application" 
version="11.1.1.49.28" id="DataBindingsNew" SeparateXMLFiles="false"
Package="adf.sample.view" ClientType="Generic">

43.10 Refactoring Limitations

Table 43-4 summarizes the limitations of JDeveloper's refactoring support.

Table 43-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 15, "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. 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 EmployeeID to EmployeeNumber. In addition, the entity Emp has an attribute called Empno that is of type EmployeeID.After creating the new domain EmployeeNumber, go to the attributes page for the entity, right-click Empno and choose Change Type. This switches Empno from EmployeeID to EmployeeNumber.

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 (.properties) files that you create. You can use this file to define labels for the attributes of entity objects. However, if you rename the .properties file you created, JDeveloper will not update the entity object definitions to reflect the new file name. As an alternative to resource bundle files that you create, you can specify a project setting to generate a single, default resource bundle file for the data model project. In this case, JDeveloper will not allow you to rename this generated file. However, if you attempt to change the project-level default resource bundle file, JDeveloper will warn you about the change. The data model project will honor the new ADF Business Components project-level setting for any objects that have not yet been linked to the default resource bundle file; all existing Business Components that have already been linked to the original default file will continue to use it instead.

.jpx project configuration file

Renaming the ADF Business Components project configuration file (.jpx) is not supported.

In previous versions of JDeveloper, ADF Business Components project configuration .jpx files were created only in the root package of the src directory of a project and were named with the same base name as the project. The ADF Business Components objects (entity objects, view objects, and application modules) were all created in the model package (for example, /model/AppModule.xml), but the /Model.jpx is not.This may cause a reusability problem when attempting to package them in ADF JAR files for use on the class path. There may be name conflicts because several projects are named Model.


43.11 Moving the ADF Business Components Project Configuration File (.jpx)

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. For more information, see Section 43.1, "About Refactoring a Fusion Web Application."

To manually move the ADF Business Components project configuration file (.jpx):

  1. 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/newpackage/name/here/Model.jpx.

  2. 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="newpackage.name.here".

  3. 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="newpackage.name.here.ScottDeptAM" DeployPlatform="LOCAL" JDBCName="scottdb" jbo.project="newpackage.name.here.Model">

  4. Change the contents of the JDeveloper project file (the.jpr file):

    • 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="newpackage.name.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/newpackage/name/here/Model.jpx"/>