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: | Utilities.actionsForPath | ||
---|---|---|---|
Product: | platform | Reporter: | Jesse Glick <jglick> |
Component: | Nodes | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | apireviews |
Priority: | P3 | Keywords: | API, API_REVIEW_FAST |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Attachments: |
Proposed patch for main
Proposed patch for contrib |
Description
Jesse Glick
2008-06-03 03:53:29 UTC
Created attachment 62397 [details]
Proposed patch for main
Created attachment 62398 [details]
Proposed patch for contrib
Please review the proposed change. looks great. It indeed removed a lot of duplicated code. I'm wondering if we could use layers to specify the complete project node popup. the profiler actions location is a clear workaround of that. The challenge there would be to combine actions that are project type specific with the ones that are to be applied to projects of any type. Right, I don't have a proposal at the moment for completely specifying project root node actions by layer. You could do something like what the MIME Lookup API does for merging SFS folders. (Which gets a bit ugly when you deal with folder ordering: positions are spread across several physical folders.) Or perhaps an entry in the folder could be a *.shadow pointing to a generic dir like Projects/Actions (not sure offhand if FolderLookup handles this), assuming you never need to interpolate project-specific actions into the block of generic actions. Such a system would probably be useful for many project types; freeform and autoproject would likely not use it since they do runtime calculation of a context menu; apisupport does too. Y01 the change does not belong to Nodes API, it is unrelated to nodes. Imho it belongs next to actionsToPopup and actionsGlobalContext. To Y01: could go into org.openide.util.Utilities. I picked NodeOp because it is generally used to implement Node.getActions() and has similarities to other methods in NodeOp used for working with context menus. Anyone else have an opinion on placement? Moved to Utilities and committed: core-main #8cda72aa3101 Will leave contrib until gets pushed to main. contrib #548925bdefcf |