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.