Bug 207004 - Misuse of @ActionReference in dlight.terminal
Misuse of @ActionReference in dlight.terminal
Status: NEW
Product: cnd
Classification: Unclassified
Component: Terminalemulator
7.2
All All
: P4 (vote)
: TBD
Assigned To: Vladimir Voskresensky
issues@cnd
: ARCH
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-06 21:01 UTC by Jesse Glick
Modified: 2012-01-11 14:57 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2012-01-06 21:01:55 UTC
LocalTerminalAction and RemoteTerminalAction specify 

@ActionID(category="Window", ...)
@ActionReference(path="Actions/Terminal", ...)

which is an incorrect idiom. Actions/*/*.instance is the actions pool, i.e. a set of all available actions, without reference to where they are shown. Each action must appear once and only once in the actions pool. Particular presentations of actions (zero or more per action) must be in some other layer folder.

TerminalContainerTopComponent.getToolbarActions seems to be the consuming code. It should pick some other folder - say, "org-netbeans-modules-dlight-terminal/toolbar" - define a public constant for this path, and have this be used in @ActionReference's.
Comment 1 Vladimir Kvashin 2012-01-11 10:11:31 UTC
I don't quite understand, could you clarify please (I probably don't understand this path well enough). I see that

1) Utilities.actionsForPath return list, not a single action

2) many actions, say, in refactoring use equal paths (RenameAction, MoveAction, SafeDeleteAction)

All these made me assume there could be multiple actions for path.

As I understand, your plan is to make each of the above mentioned paths unique (and also add info that they should be unique into ActionReference java doc). Is this correct?
Comment 2 Jesse Glick 2012-01-11 14:57:16 UTC
(In reply to comment #1)
> there could be multiple actions for path.

Yes of course. But there should not be multiple paths (under Actions/) for one action.

Each action should have exactly one registration (@ActionRegistration -> Actions/**.instance). It may have zero or more references (@ActionReference -> **.shadow) in various places (Menu/, Toolbars/, Shortcuts/, Editors/text/foo/Popup/, ad nauseam) loaded by various means such as actionsForPath, some of which expect an ordered list (hence ActionReference.position).

If you ever use a path starting with "Actions/" in either @ActionReference or actionsForPath you are doing something wrong, because merely adding an action to the pool should not affect the GUI (other than the set of actions visible in Tools > Options > Keymap).

The use of @ActionReference rather than manual layer.xml entries means that you can define a Java String constant for the path name you pick, and use it both in ActionReference.path and in the actionsForPath call, which protects against typos and assists IDE features like Find Usages.

Clearer yet?


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