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.
A lot of code in NB uses the following idiom: private void addFromLayers(List<Action> actions, String path) { Lookup look = Lookups.forPath(path); for (Object next : look.lookupAll(Object.class)) { if (next instanceof Action) { actions.add((Action) next); } else if (next instanceof JSeparator) { actions.add(null); } } } This is used especially in project type logical views to add actions defined in a folder. (DataLoader.actionsContext has rather more complex code, as it also handles setActions, and has some weird threading logic.) Sometimes an older and even more verbose variant is used that uses Repository.getDefault(), DataObject, and FolderLookup or InstanceCookie. Most of these usages could be replaced with public static List<? extends Action/*|null*/> NodeOp.actionsForPath(String path);
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