Multiplone branch needs testing

I would appreciate it if the maintainers of some of the non-Plone variants 
of Kupu could take a few moments to check whether I've broken their 
versions on my branch:

http://codespeak.net/svn/kupu/branch/duncan-multiplone

I hope nothing has broken, but if it has please either fix it if obvious or 
let me know what the problem is so I can try to fix it.

This branch allows Plone users to include multiple instances of Kupu on an 
archetypes object simply by specifying the richwidget for more than one 
field. Each kupu instance is completely independant with its own toolbar 
and popup drawers (although the state of the xml drawers is shared between 
instances since that seems the intuitive behaviour).

I've tried to maintain compatibility, but this branch has necessarily made 
some quite big changes to the way some code (especially the drawers) works.
I would like to merge the branch back to the trunk fairly quickly, but I 
don't want to break the trunk for other people when I do this. You 
shouldn't need to do anything to keep existing code running with a single 
instance, but if you want to take advantage of the multiple instance code 
it should now be quite easy.

The main change is that I've removed dependence on ids for almost 
everything. This means, for example, that all the css rules using #id are 
now changed to use .className instead (except for #kupu-colorchooser and 
#kupu-fgcolorchooser rules which so far as I can tell aren't used anywhere 
and could be removed). I've added appropriate classes (usually the same as 
the id) into the .kupu files. This is the change I most expect to have 
knock-on effects if I've got any of the CSS changes wrong.

All of the ui objects which used to be initialised using an id string can 
now take either an id or a CSS selector of the form '#id tag.class', and 
there is a new function getFromSelector which takes the string and returns 
the first matching object. e.g. instead of creating a button with the id 
'kupu-bold', you can now create a button 
'#kupu-editor button.kupu-bold'. There is also a getBaseTagClass helper 
function which takes a base node and finds a child with matching tag and 
class (this is useful if even the top level node doesn't have an id).

The biggest change is in the drawers: the external link and table drawers 
are now free from ids. The xml drawers still use the id kupu-librarydrawer 
(and a dom with a lot of other ids hanging off that), but now that section 
of DOM is created only when needed and moves around between different kupu 
instances as required. The drawertool (always supposed to be a singleton) 
now no longer depends on the editor, and its registerDrawer method takes 
the current editor as an optional third parameter.

I've left most of the ids in the .kupu files: if I can figure out how to 
write the xslt then I'll just strip them when building the Plone .html 
file: I know how to strip all ids, but I'm a bit unsure how to turn that on 
only for the Plone output file. Some of the ids for buttons in the drawers 
I removed since the only code which should be accessing them has now been 
rewritten to not require them.

I haven't yet done the change I suggested for the baseclass initialisation 
code: I can't see anywhere that it is required to support multiple 
instances, and I know at least one tool (zoom) will break. (BTW: the zoom 
tool is slightly broken on this branch: you need to press it twice to zoom 
and it displays the wrong icon. This was a bug on the trunk and is fixed 
there). I would like to merge back the multiple instance code (provided it 
hasn't badly broken any other implementations) and then work on refactoring 
the classes separately.