Comment 2 for bug 100213

I have checked in a little prototype on branch pluggable_widgets-branch

This code is highly experimental, of course, but it just seems to do
something. At least it does not break the Silva Document editor, as far
as I have tested.

 Basically the widget lookup is changed to work like the lookup of
Silva's MultiViewRegistry. Unlike the proposal of Benno the
'service_widgets' are not yet divided into subfolders, one for each
product, but other projects than the Silva core may register their own
widget folder at the service_editor.
 The rationale behind this approach is not that there is some argument
against Benno's proposal; I guess the final version should look somewhat
like that. But realising this approach now would need some migration from
the current structure, which would make testing very cumbersome.
 Thus while testing another structure is chosen which has the advantage
testers do not have to apply a no-return update to their Zope instance.

 Testing with custom content types seems to indicate there is quite some
sensible performance penalty, if caching is disabled. Additionally
there seems to be some caching issue, but this is most probably a bug in
my testing content type, which does no proper cache purge.

 A hack ensures there is no big performance penalty for Silva core
content types: if the path to a widget starts with a id which is present
in one of the roots, the acquisition magic is bypassed and a normal
lookup is performed. As all widgets in the Silva Core are prepended by
the 'service_widgets', the direct lookup is performed for them.
 This is maybe premature optimisation, but it can be easily disabled.

 The next step will be to create a SilvaDemoDocument, which is a demo
extension containing one content type deriving from Silva Document,
but adding a few silly test widgets. I would like to check this in into
the CVS, if nobody complains, because it could serve as an example how
to create customisations (if done well ...).
 After creating this demo (and most probably some fixes to the
XMLWidgets) I would like to set this issue to testing; after testing we
will see how to proceed further.