passing parameters, in plugin.xml

Hello Alain,

AR> I wish plugin.xml would allow me
AR> - to specify properties
AR> - install the same action many times, with different
AR> properties/parameters.

I think it must be only one action that get parameters from action event
context. Not a 8 different actions.

Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru

Alexey

> I think it must be only one action that get parameters from action
event context.
> Not a 8 different actions.

How do you put info in the action context, through plugin.xml?
I checked the dtd, and I see no place for that info:

<!ATTLIST action
description CDATA #IMPLIED
class CDATA #REQUIRED
text CDATA #REQUIRED
id CDATA #REQUIRED
icon CDATA #IMPLIED
popup (true | false) #IMPLIED>
<!ELEMENT keyboard-shortcut EMPTY>



Alain

Alain,
It's not exactly what you asked for, but instead of registering 8
actions in plugin.xml you could register 1 application component which
registers the actions in its initComponent() method.

Alain Ravet wrote:

Alexey

> I think it must be only one action that get parameters from action
event context. > Not a 8 different actions.

How do you put info in the action context, through plugin.xml?
I checked the dtd, and I see no place for that info:

<!ATTLIST action
description CDATA #IMPLIED
class CDATA #REQUIRED
text CDATA #REQUIRED
id CDATA #REQUIRED
icon CDATA #IMPLIED
popup (true | false) #IMPLIED>
<!ELEMENT keyboard-shortcut EMPTY>



Alain

--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

Hello Alain,

AR> How do you put info in the action context, through plugin.xml? I
AR> checked the dtd, and I see no place for that info:

In plugin.xml descriptor i can just describe you action execution point in
UI of IDEA and keystrokes for this points. The context of action must be
defined by container where those action is available and may fired.
For example, you can get Editor from event context, where action was fired.
The same way may be using and for your actions, i guess.

Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru

Martin,

> It's not exactly what you asked for, but instead of registering 8
actions in
> plugin.xml you could register 1 application component which
registers the
> actions in its initComponent() method.

my final goal is to have the 8 actions appear in the menus :

]]>

(note: at one time, only one of the set/clearXXX member pair is visible.


Alain

A real life example: I wish I could replace


by : ]]>



I'm aware it's weakening the strict checking we're having now, but I
wish I had the choice.

Alain

I didn't test the code, but try to do something like this:

public class WikiInitializer implements ApplicationComponent {

public void initComponent() {
AnAction[] actions = new AnAction[]{
// create all actions
};
ActionManager manager = ActionManager.getInstance();
addActions((DefaultActionGroup)
manager.getAction(ActionPlaces.EDITOR_POPUP), actions);
addActions((DefaultActionGroup)
manager.getAction(ActionPlaces.PROJECT_VIEW_POPUP), actions);
addActions((DefaultActionGroup)
manager.getAction(ActionPlaces.STRUCTURE_VIEW_POPUP), actions);
}

private void addActions(DefaultActionGroup group, AnAction[] actions) {
for (int i = 0; i < actions.length; i++) {
group.add(actions+);
}
}
}

Alain Ravet wrote:

Martin,

> It's not exactly what you asked for, but instead of registering 8
actions in
> plugin.xml you could register 1 application component which
registers the
> actions in its initComponent() method.

my final goal is to have the 8 actions appear in the menus :

<group id="miniWikiEditor" text="miniWiki" popup="true">
<reference id="MiniWiki.setHomeFile"/>
<reference id="MiniWiki.clearHomeFile"/>
<reference id="MiniWiki.setBugsFile"/>
<reference id="MiniWiki.clearBugsFile"/>
<reference id="MiniWiki.setTodoFile"/>
<reference id="MiniWiki.clearTodoFile"/>
<reference id="MiniWiki.setDoneFile"/>
<reference id="MiniWiki.clearDoneFile"/>
<add-to-group group-id="EditorPopupMenu" anchor="last"/>
<add-to-group group-id="ProjectViewPopupMenu" anchor="last"/>
<add-to-group group-id="StructureViewPopupMenu" anchor="last"/>
</group>

(note: at one time, only one of the set/clearXXX member pair is visible.


Alain

--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

Martin,

> I didn't test the code, but try to do something like this:


Thanks, I'll look into it, and I'll store it in my snipped repository.

but it makes me uncomfortable though,
- to replace a barely annoying code duplication by some avoidable code
complexity
- to scatter the actions setting "all over" my project. I try to keep
as much as possible in the plugin.xml, because it's the logical place
where I'll start searching in 6 months (**1).

Alain

**1: "The 6-month hospital factor" ¿
When choosing names, structures (packages), algorithms, or wondering if
I should add a comment for myself, I picture me coming back to the
project after spending 6-months in hospital. I'll have forgotten a lot
about the project, so where is the logical place/names I would look for
if I had forgotten a lot.

It's like the bus factor, but for the solo programmer :)

Alain

Hello Alain,

AR> I'm aware it's weakening the strict checking we're having now, but I
AR> wish I had the choice.

Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru

I don't think that you add that much complexity. Instead of having a
complex XML file which doesn't get updated automatically (1) you have
one single place where your whole plugin is initialized. Your actions
setting is not scattered all over the project, since it is removed
completely out of the plugin.xml. And after six months you just have to
get the initializer's class name out of the plugin.xml (which now
contains only one single entry anymore) and you're on the road again.

But of course it's a matter of taste, me personally I would prefer the
coded solution.

(1) I know it's unlikely to happen, but what if JetBrains rename
'EditorPopupMenu' to 'FileEditorPopup' or whatever? By using
ActionPlaces.EDITOR_POPUP your plugin gets either updated automatically
or you can't compile it anymore. But by using some literal text in an
XML file your plugin simply stops working - without any trace of where
to fix.

Alain Ravet wrote:

Martin,

> I didn't test the code, but try to do something like this:


Thanks, I'll look into it, and I'll store it in my snipped repository.

but it makes me uncomfortable though,
- to replace a barely annoying code duplication by some avoidable code
complexity
- to scatter the actions setting "all over" my project. I try to keep as
much as possible in the plugin.xml, because it's the logical place where
I'll start searching in 6 months (**1).

Alain

**1: "The 6-month hospital factor" ¿
When choosing names, structures (packages), algorithms, or wondering if
I should add a comment for myself, I picture me coming back to the
project after spending 6-months in hospital. I'll have forgotten a lot
about the project, so where is the logical place/names I would look for
if I had forgotten a lot.

It's like the bus factor, but for the solo programmer :)

Alain

--
Martin Fuhrer
Fuhrer Engineering AG
http://www.fuhrer.com

Alexey

The "user data" I'm trying to get access to is not in the editor. How
could it, as it comes from the plugin.xml?

Alain

Update: a cleaner solution would be to add a userData element to actions:

by ]]>
<userData name="field" value="x">
]]>

• <userData name="field" value="y">*

</action>


Jetbrains,
any objections or comment, before I post a request?


Alain

Hello Alain,

AR> The "user data" I'm trying to get access to is not in the editor.
AR> How could it, as it comes from the plugin.xml?

Currently no. You can't define permanent data context for action. And i think
that it is not realy
needed. Instead of this you may try to get access into context of actions
container where your actions is can be fired.

Thanks!
--
Alexey Efimov, Java Developer
Tops BI
http://www.topsbi.ru

Alexey

Currently no. You can't define permanent data context for action. And
i think that it is not realy needed. Instead of this you may try to
get access into context of actions container where your actions is can
be fired.

I find being able to write
]]>
<userData name="field" value="x">
]]>

• <userData name="field" value="y">*

</action>

in plugin.xml would be really useful. About the "needed", having a
second kidney is not needed, but it's useful.

Alain