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.
I need to create an action "Profile File" that is sensitive on selected file in the IDE. SInce there is already an infrastructure in place in projectsui-api, it seems that it would be best to extend the existing API in a way similar to MainProjectSensitiveAction, i.e. allow simple creation of FileSensitiveAction with ActionPerformer (in 4.0 this is not possible with FileSensitiveActions, which only operate on predefined commands).
this would probably meant to create a LookupMerger<ActionProvider> instance that would merge all action providers in the project's lookup some how. A strategy for merging needs to be defined though. profiler would then only register an ActionProvider in lookup and elsewhere it would use the ProjectSensitiveActions.projectCommandAction() factory method to create the action. is this still needed?
Change of default owner.
Indeed, this functionality is still needed. Currently profiler uses its own implementations of file- and project-sensitive actions. That leads to subtle differences in behaviour when the Project API actions are updated and the profiler ones don't catch up. In order to remove such discrepancy I've started working on #203519 which should resolve this problem by replacing the custom profiler actions with the standard project- and file-sensitive ones. While migrating to ProjectSensitiveActions.projectSensitiveAction() is rather straightforward the missing method in FileSensitiveActions makes it much harder than necessary. I am not sure whether the comment http://netbeans.org/bugzilla/show_bug.cgi?id=51571#c1 still applies. The custom performer might use eg. FileOwnerQuery.getOwner(file).getLookup().lookupAll(ActionProvider.class) to obtain all the registered ActionProvider instances applicable to the given file.
Created attachment 114622 [details] Proposed patch
(In reply to comment #3) > I am not sure whether [comment #1] still applies. The custom > performer might use e.g. > FileOwnerQuery.getOwner(file).getLookup().lookupAll(ActionProvider.class) to > obtain all the registered ActionProvider instances applicable to the given > file. I think what mkleint was saying was that the project should use LookupProviderSupport.createActionProviderMerger anyway, in which case one way of implementing similar functionality would be to register an ActionProvider in the project's lookup which handles just one command, and then call FileSensitiveActions.fileCommandAction to create an action which runs it. This might handle many common cases. Still, a fileSensitiveAction factory may make sense for some uses and should be present for parity. The impl diff is too big for me to follow completely, but the API looks basically good. [JG01] "</code>method" in apichanges.xml Also <date> must be set to date of actual integration. [JG02] Javadoc of fileSensitiveAction looks to have been blindly copied and needs to be edited in several places.
Created attachment 114725 [details] updated patch Addressing [JG01] and [JG02]
[JG03] Use @NullAllowed on the icon parameter.
Created attachment 114755 [details] updated patch re. [JG03] Added @NullAllowed for icon and took the liberty to add @NonNull for performer and name parameters.
If there are no more comments I'll integrate the patch on 2012/01/13
[JG04] Missing @since on fileSensitiveAction. (No need to post a new patch for trivial stuff like this, just a reminder.)
Patch integrated. http://hg.netbeans.org/profiler-main/rev/c80cd7e4766e
Integrated into 'main-golden', will be available in build *201201250600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c80cd7e4766e User: Jaroslav Bachorik <yardus@netbeans.org> Log: #51571: Intorducing API for creating FileSensitiveAction with special performer