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
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]
(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
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]
Addressing [JG01] and [JG02]
[JG03] Use @NullAllowed on the icon parameter.
Created attachment 114755 [details]
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.)
Integrated into 'main-golden', will be available in build *201201250600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Bachorik <email@example.com>
Log: #51571: Intorducing API for creating FileSensitiveAction with special performer