VW InsyncRefactoring

Visual Web - Insync - Refactoring

This document is currently being worked on

Contents


Issue (FEATURE) 90532 - Migrate Visual Web refactoring to new Refactoring APIs

Status

Date Description
19 Jan 2007 Initial Document


Abstract

This task involves use of the new Refactoring APIs.

Background

Up until NetBeans 5.5, the Refactoring implementation was very Java centric. Starting in NetBeans 6.0, Refactoring support is being converted into a language neutral API. In other words thge new Refactoring API will allow registration of refactoring actions through the use of ActionsImplementationProvider for any type of file and will allow invocation of the refactoring machinary through the use of Refactoring Plugin Factories.

Refactoring API Review

The review of new Refactoring API is scheduled:

Feb 13, 2007 The API review completed with TCRs and TCAs. There are going to be several changes to the refactoring APIs:

  1. Lookup will be used in place of Object for the all Refactoring classes (RenameRefactoring, MoveRefactoring etc). (TCR)
  2. The BackupFacility may be made a pluggable functionality. One possible implementation of it could be based on LocalHIstory module. (TCA)
  3. How to configure the refactoring actions in the popup menu will be documented. (TCR)
  4. What is put in the Lookup when performing Java refactorings will be documented. (TCR)

Description

In Visual Web Pack 5.5, the refactoring was implemented by piggy backing on and extending the Java refactoring through the use of Refactoring Plugins. In NetBeans 6.0, Visual Web will make use of the new Refactoring API to implement the refactoring functionality.

In NetBeans 6.0 it is highly likely that the Visual Web will tightly integrate with the NetBeans Web Project. This will also affect the refactoring functionality of Visual Web will be implemented. FOr example, the base NetBeans Web Project may take care of adjusting the managed bean entries are modified in the faces-config file when the managed bean's Java class is renamed. Thus Visual Web will not have to implement the same iitem in the rename refactoring of Java class. The Visual Web will only perform the additional refactorings that are required for it to work.

Requirements

This is a P0 requirement.

  1. Insync should use the new refactoring APIs.
  2. Insync should use or plug into the mechanisms provided by the base NetBeans Web project refactoring support.

Functional Specs

The Insync refactoring will use make use of the new refactoring APIs to implement the non java refactoring. This includes the way the refactoring actions are registered and handled. It is being currently discussed whether Insync needs to do the registration of actions itself e.g. for JSP file or will it be provided by the base NetBeans Web projects JSP mimetype based action registration.

Design Specs

Add refactoring actions to JSP pages in VW project

  • Add the RefactorAll popup menu action to the Loaders/text/x-jsp/visual/Actions folder of the project/jsfloader/src/org/netbeans/modules/visualweb/project/jsfloader/layer.xml. This layer file location is used by the JsfJspDataLoader to build the pop up menu on .jsp files.
  • In the setName() method of JsfJspDataNode invoke the RenameRefactoringAction. This enables the invocation of Rename refactoring for VW JSP pages.

Add support for invokation of refactoring oprtaions to JSP pages in VW project

  • Register the implementation of org.netbeans.modules.refactoring.spi.ui.ActionsImplementationProvider using the file with same name in visualweb/insync/srcMETA-INF/services folder. The implementation class is org.netbeans.modules.visualweb.insync.faces.refactoring.FacesRefactoringActionsProvider. This class implements the methods to determine if it can handle rename, move, safe delete, copy operations on the refactored entities. This class currently return true for rename and move refactoring query of VW JSP pages. It also return true for to the rename and move refactoring query of folders under the VW project's web folder. The refactorings are not allowed on the folders named web/META-INF, web/WEB-INF, web/resources. This results in the enablement of Refactor:Rename... and Refactor:Move... actions. When the refacting action is actually invoked it creates the appropriate refactoring parameter dialogs org.netbeans.modules.visualweb.insync.faces.refactoring.FacesMovePanel and org.netbeans.modules.visualweb.insync.faces.refactoring.FacesRenamePanel using the org.netbeans.modules.visualweb.insync.faces.refactoring.FacesMoveRefactoringUI and org.netbeans.modules.visualweb.insync.faces.refactoring.FacesRenameRefactoringUI classes respectively. These parameters dialogs may get invoked directly e.g. the FacesMovePanel dialog may get invoked due to a drag and drop operation on the VW JSP page, the FacesRenamePanel dialog may get invoked due to the in-place rename of VW JSP page node in the Projects or Files window. In such cases the parameters of the refactoring operation are prefilled and are read-only.

Add support for refactoring validation and oprtaions to JSP pages in VW project

  • Register the implementation of org.netbeans.modules.refactoring.spi.RefactoringPluginFactory using the file with same name in visualweb/insync/srcMETA-INF/services folder. The implementation class is org.netbeans.modules.visualweb.insync.faces.refactoring.FacesRefactoringsPluginFactory. This class creates the instances of org.netbeans.modules.visualweb.insync.faces.refactoring.FacesMoveRefactoringPlugin and org.netbeans.modules.visualweb.insync.faces.refactoring.FacesRenameRefactoringPlugin in response to invokation of Move and Rename refactoring respectively.
  • The FacesMoveRefactoringPlugin performs the necessary validation of parameter of Move refactroing. It primary handles Move refactoring of VW JSP Pages. It also handles the Move reafactoring of folders under VW project's web folder (not implemented yet!). The FacesMoveRefactoringPlugin takes care of Move refactoring within, between VW Projects. It also takes care of the Move refactoring from VW Web project and other projects.
  • The FacesRenameRefactoringPlugin performs the necessary validation of parameter of Rename refactroing. It primary handles Rename refactoring of VW JSP Pages. It also handles the Rename reafactoring of folders under VW project's web folder (not implemented yet!).
  • Both these classes also keep track of which object the user invoked the refactoring operation on. If the refactoring was invoked on VW Page, they delegate the Java side refactoring to the implementation in the refactoring/java module. The mechanism of delegation is described in the Refactoring API FAQ. If the refactoring was invoked on the Java file that corresponds to a Managed Lifecycle bean i.e. sub class of AbstractRequestBean, AbstractSessionBean, AbstractApplicationBean, these classes add the necessary RefactoringElements to perform VW JSP page refactoring - specifically value binding expressions, start page refactoring etc. The <class-name> tag refactoring is handled by the web/jsf module. The <bean-name> refactoring is handled by Insync refactoring. If the refactoring was invoked on the Java file that corresponds to a VW JSP page i.e. sub class of AbstractPageBean these classes delegate the refactoring to themselves through the invocation of the same refactoring with the VW page file object as the refactored source which comes back through the FacesRefactoringsPluginFactory.

Tasks

Team Members

Random Notes

Data Objects to deal with

  1. Jsf Jsp Data Object (for .jsp corresponding to the Visual Web page e.g. PageNNN.jsp)
  2. Jsf Java Data Object (for page backing managed bean e.g. PageNNN.jsp)
  3. Java Data Object (for non-page lifecycle managed beans e.g. RequestBeanNNN.java, SessionBeanNNN.java, ApplicationBeanNNN.java)
  4. Java Data Object (for non-page non-lifecycle managed beans e.g. LoggedInUserBean.java)
  5. Java Data Object (for non-managed beans e.g. Utilities.java)

The refactoring actions for the 1st will be provided by Visual Web extension support.
The refactoring actions for the 2st will be provided by Visual Web extension support. Is this a correct assumption? Or will the actions be provided by the base NetBeans java project support.
The refactoring actions for the 3rd will be provided by base NetBeans java project support.
The refactoring actions for the 4th will be provided by base NetBeans java project support.
The refactoring actions for the 5th will be provided by base NetBeans java project support.

The refactoring plugins and elements for the 1st will be provided by Visual Web extension support.
Some additional refactoring plugins and elements for the 2st will be provided by Visual Web extension support. Is this a correct assumption? Or will the actions be provided by the base NetBeans java project support.
Some additional refactoring plugins and elements for the 3rd will be provided by base NetBeans java project support.
Some additional refactoring plugins and elements for the 4th will be provided by base NetBeans base web project support.
The refactoring plugins and elements for the 5th will be provided by base NetBeans base web project support.

Actions

  • Rename
  • Move
  • Copy
  • Safe Delete(?)

Reference Material

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo