About "Making plugin development easier"

http://blogs.jetbrains.com/yole/archives/000059.html

Dmitry,

that's some very sweet stuff actually, especially creating Actions has always been a major
pain to do. That action-editor is a good thing, although personally, I wouldn't have
hooked this into the "New" menu, but would have favored a "Visual Descriptor Editor", like
it's available for editing J2EE descriptors. Any plans/chances to get one as well?

Something I miss on the screenshot is the ability to assign shortcuts to an action.
Getting this right can be a lottery sometimes: Was it "ctrl" or "ctl" or "control" for the
modifier key? Does it matter if the modifier/key is written in lower/upper case? That's
something that could be done automatically by the editor. Borrow the shortcut-control from
the keymap-settings.

One issue I have with the current New -> *Component feature is that it's only available in
plugin modules. If you're using a (simple) plugin module that depends on plain java
modules, you're out of luck. I think this should be available for any (java) module that
is a dependency of a plugin module. If it's used by more than one plugin module, it should
ask which to update.

This also doesn't integrate very well with the "Coding by Intention" style: I have created
the last bunch of components with the "Create Class" intention. So there should be some
support to update the plugin.xml from the code and keep it in sync with it. I can imagine
some new inspections:

- Component/Action not registered in plugin.xml. QuickFix: Register/Open Action-Editor.
This should use the same module dependency rules as above. (Actions are a bit tough
actually as they can be created dynamically. This needs some thought)

- Incorrect component/action registration: Checks if the type of a component matches its
registration in plugin.xml. It gives some funny exceptions when a component doesn't
implement the interface required by the registration. This could be available both in code
as well as the plugin.xml.

Something else I found in http://www.jetbrains.com/idea/plugins/plugin_structure.html:

"Note that two components of the same level (Application, Project or Module) cannot have
the same interface class."

That should read "the same implementation class", doesn't it?


Sascha

6 comments

Hello Sascha,

First of all - if you would like to get commit access to DevKit sources,
just ask. :)

SW> that's some very sweet stuff actually, especially creating Actions
SW> has always been a major pain to do. That action-editor is a good
SW> thing, although personally, I wouldn't have hooked this into the
SW> "New" menu, but would have favored a "Visual Descriptor Editor",
SW> like it's available for editing J2EE descriptors. Any plans/chances
SW> to get one as well?

Do you really think it's necessary? In my experience, I don't change most
of the actions once they have been created, and if I do need to change something,
it's usually simple enough so that editing the XML is faster.

SW> Something I miss on the screenshot is the ability to assign
SW> shortcuts to an action. Getting this right can be a lottery
SW> sometimes: Was it "ctrl" or "ctl" or "control" for the modifier key?
SW> Does it matter if the modifier/key is written in lower/upper case?
SW> That's something that could be done automatically by the editor.
SW> Borrow the shortcut-control from the keymap-settings.

I've added this today. Simply didn't have the time to finish it yesterday.
:)

SW> One issue I have with the current New -> *Component feature is that
SW> it's only available in plugin modules. If you're using a (simple)
SW> plugin module that depends on plain java modules, you're out of
SW> luck. I think this should be available for any (java) module that is
SW> a dependency of a plugin module. If it's used by more than one
SW> plugin module, it should ask which to update.

JIRA request please?

SW> This also doesn't integrate very well with the "Coding by Intention"
SW> style: I have created the last bunch of components with the "Create
SW> Class" intention. So there should be some support to update the
SW> plugin.xml from the code and keep it in sync with it. I can imagine
SW> some new inspections:
SW>
SW> - Component/Action not registered in plugin.xml. QuickFix:
SW> Register/Open Action-Editor. This should use the same module
SW> dependency rules as above. (Actions are a bit tough actually as they
SW> can be created dynamically. This needs some thought)
SW>
SW> - Incorrect component/action registration: Checks if the type of a
SW> component matches its registration in plugin.xml. It gives some
SW> funny exceptions when a component doesn't implement the interface
SW> required by the registration. This could be available both in code
SW> as well as the plugin.xml.

Again, JIRA requests please? If you would like to implement those, you're
welcome. :)

SW> Something else I found in
SW> http://www.jetbrains.com/idea/plugins/plugin_structure.html:
SW>
SW> "Note that two components of the same level (Application, Project or
SW> Module) cannot have the same interface class."
SW>
SW> That should read "the same implementation class", doesn't it?

No, the documentation is correct. getComponent(), which receives the interface
class as parameter, can return only one component implementation. At the
same time, a class implementing multiple interfaces can be registered as
a component multiple times with different interface classes.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

Hi Dmitry,

First of all - if you would like to get commit access to DevKit sources,
just ask. :)


Hmm, gotta think about this. If that means to get a shiny IntelliJ icon, it's
really tempting ;)

SW> "New" menu, but would have favored a "Visual Descriptor Editor",
SW> like it's available for editing J2EE descriptors. Any plans/chances
SW> to get one as well?

Do you really think it's necessary? In my experience, I don't change
most of the actions once they have been created, and if I do need to
change something, it's usually simple enough so that editing the XML is
faster.


No doubt, making changes is certainly easier in XML when you know what you're
doing, but a visual editor could have more power to guide a new or less
experienced user through editing the file. One example: While it's hard to find
out how to make a ProjectComponent's settings go to the .iws instead of the .ipr
file, a visual editor would make this very easy by presenting a checkbox with an
explanatory tooltip.

However there are for sure more important things to do :)

SW> SW> That should read "the same implementation class", doesn't it?

No, the documentation is correct. getComponent(), which receives the
interface class as parameter, can return only one component
implementation.


Hmm, now you got me confused. There's also getComponents(Class) that returns all
implementations of the specified interface class. How is that supposed to work
if an interface can only be specified once?

At the same time, a class implementing multiple interfaces can be registered as
a component multiple times with different interface classes.


Ah, OK. Though it would probably be more intuitive if a component could specify
more than one interface class than to require several components with the same
implementation but different interfaces. Intuitively, I'd say that such a
configuration would end up with a "component name collision" error. It's
probably a good idea to explicitly point that out in the documentation :)

Sascha

0

Hello Sascha,

>> SW> "New" menu, but would have favored a "Visual Descriptor Editor",
>> SW> like it's available for editing J2EE descriptors. Any
>> plans/chances SW> to get one as well?
>>
>> Do you really think it's necessary? In my experience, I don't change
>> most of the actions once they have been created, and if I do need to
>> change something, it's usually simple enough so that editing the XML
>> is faster.
>>
SW> No doubt, making changes is certainly easier in XML when you know
SW> what you're doing, but a visual editor could have more power to
SW> guide a new or less experienced user through editing the file. One
SW> example: While it's hard to find out how to make a
SW> ProjectComponent's settings go to the .iws instead of the .ipr file,
SW> a visual editor would make this very easy by presenting a checkbox
SW> with an explanatory tooltip.

I don't think this single option makes implementing a visual editor worthwhile.
It's much easier to generate the option in the "false" state by default.

>> SW> SW> That should read "the same implementation class", doesn't
>> it?
>>
>> No, the documentation is correct. getComponent(), which receives the
>> interface class as parameter, can return only one component
>> implementation.
>>
SW> Hmm, now you got me confused. There's also getComponents(Class) that
SW> returns all implementations of the specified interface class. How is
SW> that supposed to work if an interface can only be specified once?

It returns the components whose interface-class is a subclass of the class
passed as the method parameter.

>> At the same time, a class implementing multiple interfaces can be
>> registered as a component multiple times with different interface
>> classes.
>>
SW> Ah, OK. Though it would probably be more intuitive if a component
SW> could specify more than one interface class than to require several
SW> components with the same implementation but different interfaces.
SW> Intuitively, I'd say that such a configuration would end up with a
SW> "component name collision" error. It's probably a good idea to
SW> explicitly point that out in the documentation :)

Yes, the documentation indeed can be improved...

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0

OK, I think I got it, although this is not really intuitive: The
"interface-class" is actually just a key that can be used to retrieve the
component and has little to do with inheritance. It can be an arbitrary class
that is totally unrelated to the component's implementation-class. Something
like this does indeed work:

java.lang.String com.foo.bar.Dummy The requirement that the classes must be assignment-compatible is merely a side-effect of the generic method signature of getComponent() T getComponent(Class]]> interfaceClass);

and
final String component = application.getComponent(String.class);

will of course crash at runtime.

That's kinda weird but explains a few strange things I've seen. You learn
something new every day :)

Sascha

0

Dmitry,

This looks really great! While I could easily come up with dozens of ways to extend and improve what you have done (including a lot of those already mentioned or JIRAed), I think I can safely estimate that you've covered about 85% of the fiddly headache of starting up a new plugin.



--Dave Griffith

0

Please sign in to leave a comment.