With Se 2.0′s first alpha out yesterday, it is really time to start looking at Se-IDE 2.0. I strongly think the first thing that should happen is to take the approach Firebug did and remodel it as a plugin system. For the reasons behind this, see Conspiring out loud about Selenium-IDE 2.0. For this post though, I’m going to just pretend that you have bought into this idea and just describe what such an API / plugin would look like / do.
- Plugin Registration – A plugin needs to somehow tell the main Se-IDE plugin that it is on the machine, and is enabled
- Plugin Discovery – Check whether a given other Se-IDE plugin is installed, and that the version meets a minimum level
- Create Options Page – Imagine you were writing a Flash plugin; you would likely want a new tab to have various switches and toggles on how to do things specific to that plugin
- Modify Options Page – Sometimes you don’t need a whole new tab for configuration of your plugin, so you can modify an existing config page
- Add Formatter – Want to add a new language to Se-IDE? It’s actually not that hard. I see this being a huge area of possibility for plugins. And it lets people who are not ‘core’ developers for Selenium create and maintain formatters. This should reduce the lag in getting things fixed in them. This would also require an RC client as well, but that is also less of a challenge.
- Add Locator – This could also be a big win. Want Prototype style CSS selectors? Add a plugin. (And server side support.)
- Add Command – I see this sort of functionality being used heavily, especially by things like a Flash plugin. I can almost guarantee that there are special commands that would be needed only by so they should be added in.
What else would be necessary? Other than lots of documentation about how to do this with lots of sample code. Nothing is worse than an API that just has the method descriptions and no actual implementation examples.

I’ve been reading your posts on Se IDE and I definitely think plugins would be a great way to get the community involved and to decrease the offshoots starting to appear like Molybdenum, which has more features than Se IDE, such as code blocks that can be included in multiple tests, but I just don’t like the interface as much as Se IDE.
Ease of use is very important so I feel the plugins should all require a structure for commenting functionality so the IDE can keep the user informed on how to do things in a similar way for all plugins.