This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Unnecessary API additions in Project API for Delete Project | ||
---|---|---|---|
Product: | projects | Reporter: | Jesse Glick <jglick> |
Component: | Generic Infrastructure | Assignee: | Jan Lahoda <jlahoda> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | abadea, mfukala, rnajman |
Priority: | P2 | Keywords: | API |
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 58866 |
Description
Jesse Glick
2005-07-20 02:02:11 UTC
Again, sorry for late notice, but better to do a little refactoring now than be stuck with the wrong design decision permanently. No problem regarding the late notice. As you noted, better change it now. I will try to answer in the order of importance: 1. Re putting the DeleteOperationImplementation into the project lookup: this is to support the API part (ProjectOperations). The reason for ProjectOperations is the J2EE project (and similar, if any), which may encapsulate EJB project and Web project (these projects may be created by the New Project wizard altogether with the J2EE project). If the delete action is called on the J2EE project, a special dialog allowing the user to delete also the EJB and web projects should appear. If this could be solved in an another way, the API part should be deleted and AntProjectHelper.performDefaultDeleteOperation(DeleteOperationImplementation) should be used instead. 2. Regarding placing of ProjectOperations, ProjectOperationsImplementation: these are not related to ant/project (probably make at least some sense to any project type), so I placed them into Projects API. Can be moved into ant/project if you think it is a better place. But I would rather move the default delete operation into projectuiapi as you mentioned. 3. Re performClean name: I would like to change the name of this method to notifyDeleting (or some similar name), so there would be pair notifyDeleting-notifyDeleted like in Window listener: windowClosing-windowClosed. Re. #1 - OK, I did not know about this aspect of it. If you decide to keep PO/POI where they are, probably it would make sense to document this use case: a container project which wishes to delete contained projects in one step and thus expects to find POI.DOI in lookups of the contained projects. It should just be clarified in Javadoc that a project is under no obligation to use these classes for implementing AP.COMMAND_DELETE. If the standard infrastructure were all moved to projectuiapi in a .spi.support package, that would also make things clearer, I think. Re. #3 - makes sense, and also note ModuleInstall.{closing,closed}. Some other nits: a. ProjectOperations should probably not be instantiable at all; can just make every method static. b. ProjectOperationsImplementation could be deleted and its nested interfaces made into top-level source files. (Generally we try to avoid exposing nested classes in APIs.) c. POI.* interfaces need to document that they should be added to Project.lookup in order to be used, I guess (depending on what you want the style to be re. #1). I did some adjustments as specified in issue #61546. Please let me know if you have another ideas. |