Bug 180979 - Layer based registration of ToolsActions
Layer based registration of ToolsActions
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Actions
6.x
Other Linux
: P4 (vote)
: 6.x
Assigned To: Jaroslav Tulach
issues@platform
: API_REVIEW_FAST
Depends on:
Blocks: 140390
  Show dependency treegraph
 
Reported: 2010-02-19 11:27 UTC by Jaroslav Tulach
Modified: 2010-02-27 22:07 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Proposed API change and its usage and implementation (35.59 KB, patch)
2010-02-19 11:33 UTC, Jaroslav Tulach
Details | Diff
New implementation without changes in o.n.core (30.75 KB, patch)
2010-02-22 07:21 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2010-02-19 11:27:44 UTC
Instead of registering tools actions in manifest, read the from layer.
Comment 1 Jaroslav Tulach 2010-02-19 11:33:41 UTC
Created attachment 94347 [details]
Proposed API change and its usage and implementation
Comment 2 Jesse Glick 2010-02-19 13:18:19 UTC
BTW please do unrelated cleanups of warnings (like adding @Override) in a normal commit prior to making the patch, so as to avoid cluttering the diff with a lot of stuff not relevant to the change you want to make.


[JG01] I don't think any new API is needed at all. You can already register actions in menus however you like, whether in the Tools menu or elsewhere; and you can use DynamicMenuContent to conditionally hide them. (I would love to see an easier and more efficient way to conditionally display actions, which could be used in a lot of places, but that is for a separate API review.)

It looks like we have <10 such actions, so converting them should not be a big deal. Making another magical global place to dump unrelated actions doesn't seem like a good idea to me.

In other words, it is not just manifest registration of actions that we need to deprecate, but ToolsAction itself. Deprecate it, remove it from the Tools menu, and tell people to use regular action registration.

Subsequent comments pertain to the current patch but I think it is the wrong direction.


[JG02] "ToolActions", not "ToolsActions".
                               ^

[JG03] If openide.actions is to define the layer location, it should be actually define the <folder> in its own layer.xml.


[JG04] apichanges.xml should say deprecation="yes".


[JG05] The patch to j2ee.sun.appsrv81 looks suspicious. manifest.mf is not touched, and org-netbeans-modules-j2ee-sun-ide-j2ee-runtime-actions.instance looks like a CNFE.
Comment 3 Jaroslav Tulach 2010-02-22 07:21:18 UTC
Created attachment 94388 [details]
New implementation without changes in o.n.core

The new patch is addressing Jesse's comments. I also agree that the tools action shall be subject for elimination, and I may use that in my conversation with the providers of such actions (Analyse folder, create a unit test, etc.), however I still prefer to implement this new API.
Comment 4 Jaroslav Tulach 2010-02-26 15:31:34 UTC
About to integrate soon.
Comment 5 Jaroslav Tulach 2010-02-26 22:50:44 UTC
core-main#f1009ecb3a36
Comment 6 Quality Engineering 2010-02-27 22:07:17 UTC
Integrated into 'main-golden', will be available in build *201002280200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/f1009ecb3a36
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #180979: Allow layer declared action instances to participate in ToolsAction


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