Here’s a quote from The Basics of Plugin Development for IntelliJ IDEA:
A more complex example for getting a container inside the event handler is presented below. In this example, the DataContext class is used for passing context references for the considered action. This class deserves special attention, and we will consider it in detail in another article devoted to actions and passing context parameters principles.
And here’s some following example code from this article:
public class MyAction extends AnAction {
public void actionPerformed(AnActionEvent e) {
DataContext dataContext = e.getDataContext();
Project project = (Project)dataContext.getData(DataConstants.PROJECT);
Module module = (Module)dataContext.getData(DataConstants.MODULE);
}
}
In context of my previous post, this is just another example of what I mean when I ask for more declarative APIs. Sure, I understand certain reasons for using “identifiers” to retrieve Objects from some kind of object container. And it may very well make absolute sense for the JetBrains guys to do it this way. But expose such an API? To a potential external plugin developer? Smells strange, doesn’t it?
And what would the problems be when offering an alternative API using a more declarative style like for example this:
... {
project = dataContext.getProject();
module = dataContext.getModule();
...
}
Of course, you can’t have a million getThis, getThat, etc methods in the DataContext API. But is this a valid argument against a more declarative API? Or an argument for an ID-based “query-API”? I don’t think so. All it means is, that something is not they way it should be.
The question should probably be more like: How can I separate the DataContext thing into sub contexts? Or can I provide specialized contexts depending on the kind of “plugin component part” I’m currently working on.
Enough of this..
There’s something above all that.. It has to do with arguments “Why Ruby is better?” and the like. It runs along these lines:
If you’re used to coding in a more dynamic language, you probably come to like how you can implement a lot of things with very little code. (Let’s leave all strong-typing related matters aside for now. They don’t matter here.) In this context I kind of hate Jave. Obviously.. :)
BUT: I still think arguments like “Java + IDEA” vs “Ruby + ???” saying basically that with Ruby you’re pretty much stuck with typing everything yourself are.. well.. valid in a way. Not so much as to count number of key strokes and compare them. But like.. with a nice Java API and a nice Java IDE, the IDE can actually “guide” you through what you want to acomplish.
In Ruby (for example) you’re pretty much stuck with reading docs (remember the days of JDK1.1 and 1.2? I do.. :) and/or trusting your guts. Of course things are not as bad for Ruby as they may sound here. Writing Ruby is a lot of fun, and you’re guts are right a lot of times. And a test-driven approach helps a lot to keep a nice development speed in Ruby.
But Java, with the right APIs and the right IDE, can make 90% of the coding work a real breeze. You still write a lot more code than in Ruby, no doubt about that. But you proabably have to, because of some limitation that’s still present in the Ruby world, or some legacy argument forcing you to use Java. But with appropriate APIs that help the IDE to guide you, Java coding isn’t that bad.
This is my problem with looking at the pluging development stuff offered by IDEA.. You know what I mean?
tfdj
Filed by The.French.DJ at 3:26 am under Development,Java
2 Comments