Twitter github

Hunting Wabbits and Magical Identifiers

I always like to chuckle about my past Eclipse programming experiences. I remember one of my earlier tasks involved showing the error log view for something. I thought that the workbench would be responsible for that somehow… and I was right!

PlatformUI.getWorkbench().findView(...)

However, to my dismay, the parameter was a magical identifier that I didn’t know. It took me awhile to wade through Eclipse source code to find the identifier. An by awhile, I mean more time than it should have taken. There are much better ways to find magical identifiers these days… here are two ways:

(1) Plug-in Registry View

The Plug-in Registry view allows you to quickly find information regarding plug-ins and extension points. If you’re just interested in extension points, I’d set a filter to show only extension content only:

After that, you’re presented with a list of extension content only. Let’s focus on org.eclipse.ui.views as that’s our extension point of interest here:

Next, let’s try to find that pesky log view identifier:

That wasn’t so bad now, was it :)?

(2) Plug-in Spy

In Eclipse 3.4, it will be even easier to find certain types of identifiers using the Plug-in Spy. You just have to look at what you want and press ALT+SHIFT+F1:

Ok, those are all the tips today from your friendly PDE developer 🙂

  • Boris Bokowski

    Hi Chris, you got lucky in (1) because the identifier for the view included the string “log”. Try to find the identifier for the Outline view instead. The filtering in the Plug-in Registry view could be a little bit smarter and show all children of matching nodes, or it could try harder to maintain selection when you click on the button to remove the filter.

  • Boris Bokowski

    Hi Chris, you got lucky in (1) because the identifier for the view included the string “log”. Try to find the identifier for the Outline view instead. The filtering in the Plug-in Registry view could be a little bit smarter and show all children of matching nodes, or it could try harder to maintain selection when you click on the button to remove the filter.

  • Chris Aniszczyk (zx)

    I know, but don’t ruin a good blog post Boris 🙂

    Feel free to file a bug 🙂

  • Chris Aniszczyk (zx)

    I know, but don’t ruin a good blog post Boris :)Feel free to file a bug 🙂

  • Bull

    Although common practice is still to define a constant in the plugin somewhere and then type the identifier out in the plugin.xml. I never really liked having to type the same string in two places (once in XML and then again in Java). I know refactoring is pretty good, but I seem to misspell almost every identifier :-).

    Hey, I wonder if we could have some sort of annotation so that if I define a plugin constant, that isn’t in my plugin.xml, I get a warning, and auto completion for plugin identifiers would be really cool… maybe Eclipse 4.0 🙂

  • Bull

    Although common practice is still to define a constant in the plugin somewhere and then type the identifier out in the plugin.xml. I never really liked having to type the same string in two places (once in XML and then again in Java). I know refactoring is pretty good, but I seem to misspell almost every identifier :-). Hey, I wonder if we could have some sort of annotation so that if I define a plugin constant, that isn’t in my plugin.xml, I get a warning, and auto completion for plugin identifiers would be really cool… maybe Eclipse 4.0 🙂