Bug 51571 - Need API for creating FileSensitiveAction with special performer
Need API for creating FileSensitiveAction with special performer
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
4.x
All All
: P3 (vote)
: 7.2
Assigned To: J Bachorik
issues@projects
: API, API_REVIEW_FAST
Depends on: 209518
Blocks: 203519
  Show dependency treegraph
 
Reported: 2004-11-16 16:24 UTC by iformanek
Modified: 2012-03-13 14:02 UTC (History)
3 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch (31.04 KB, patch)
2012-01-04 13:53 UTC, J Bachorik
Details | Diff
updated patch (31.01 KB, patch)
2012-01-09 09:05 UTC, J Bachorik
Details | Diff
updated patch (31.55 KB, patch)
2012-01-10 09:38 UTC, J Bachorik
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description iformanek 2004-11-16 16:24:19 UTC
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).
Comment 1 Milos Kleint 2008-10-14 13:12:34 UTC
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?
Comment 2 Antonin Nebuzelsky 2010-03-29 14:10:01 UTC
Change of default owner.
Comment 3 J Bachorik 2012-01-04 13:52:42 UTC
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.
Comment 4 J Bachorik 2012-01-04 13:53:34 UTC
Created attachment 114622 [details]
Proposed patch
Comment 5 Jesse Glick 2012-01-06 22:15:37 UTC
(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.
Comment 6 J Bachorik 2012-01-09 09:05:27 UTC
Created attachment 114725 [details]
updated patch

Addressing [JG01] and [JG02]
Comment 7 Jesse Glick 2012-01-09 15:43:05 UTC
[JG03] Use @NullAllowed on the icon parameter.
Comment 8 J Bachorik 2012-01-10 09:38:34 UTC
Created attachment 114755 [details]
updated patch

re. [JG03]
Added @NullAllowed for icon and took the liberty to add @NonNull for performer and name parameters.
Comment 9 J Bachorik 2012-01-12 10:52:28 UTC
If there are no more comments I'll integrate the patch on 2012/01/13
Comment 10 Jesse Glick 2012-01-12 14:22:35 UTC
[JG04] Missing @since on fileSensitiveAction.

(No need to post a new patch for trivial stuff like this, just a reminder.)
Comment 11 J Bachorik 2012-01-13 08:46:20 UTC
Patch integrated. 

http://hg.netbeans.org/profiler-main/rev/c80cd7e4766e
Comment 12 Quality Engineering 2012-01-25 16:29:36 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo