Re: Multiplone branch needs testing

On Mar 9, 2005, at 12:04 PM, Duncan Booth wrote:

> 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).

That's a really useful decision.  Not only is it good for the author, 
it's a lot, LOT simpler for the administrator.   I can imagine the pain 
and confusion of configuring multiple library source sets.  Bleh.

> 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

Is this also true for the xpath expressions in the XML data?

> 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

Ahh, that answers it, errr, maybe.

> (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.

Well done!

--Paul