Plugging in XML widgets

[Martijn Faassen]

It would be nice if there was a way to add new widgets
to the service_widgets tree. This could be solved in
a similar way the MultiViewRegistry allows the plugging
in of new views by having multiple trees. Implementing this
is a fairly complicated exercise, though.

[Clemens Robbenhaar (crobbenhaar)]

I will try to do a 'spike solution' (aka throw away
prototype) which will be checked in on a branch in
XMLWidgets (if it does work for me ...).

 Most probably this will need some hooks in the
EditorService._resolveWidgetPath and the
WidgetRegisty.getWidget
(and some more, as I will figure out under way ;-)

[Clemens Robbenhaar (crobbenhaar)]

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.

[Clemens Robbenhaar (crobbenhaar)]

A quite long time ago I promised to create some examples how the
pluggables widgets may work, for one can test and evaluate the changes
on the pluggable_widgets-branch.

 This finally happened with the 0.1 release of the
SilvaSampleContentTypes branch.

 The state of the branch is still quite ugly/hackish; it needs
some code cleanup etc. Especially the organization of the widgets inside
the 'service_widgets' needs to be done (the sample currently creates its
own widget folder in the Silva root yet ...) and the caching should be
reenabled.

 Oh, and then this would involve a non trivial upgrade of Silva, if this
is really going to be merged. As all of these issues are quite involved,
and an integration of this "wish" feature is quite risky, I will keep
the current issue in its current state, and tend to resolve it (as there
is no 'reject' status yet), if nobody else is interested. If I am the
only one interested in this feature, it is maybe better to abandon it,
as I can live with the current state, maintaining my local hack.

[Clemens Robbenhaar (crobbenhaar)]

I am currently stuck with a problem how to implement the traversal
through several of the "plugged-in" widget roots. Any comments on the
problem would be appreciated.

 In a similar approach to the one Silva uses to handle plugged-in views,
currently one can define several "widget roots", which are folders (or
directory views), and which are consecutively searched for the wanted
widgets. The problem is the proper ordering of the widget roots.

 a) The current approach is to add widget roots to the editor service,
  where they are maintained in an ordered list, in order of registration.

  i.e. in the "install" of the product one has a line like:

   root.service_editor.addWidgetRoot('service_sample_widgets', depends_on=('service_widgets',) )

   This is straight forward and works only as long as products are installed
  in the order they depend on each other.

   Example: If ProductA has a 'service_a_widgets' root and ProductB has
  a 'service_b_widgets' root, and ProductB depends on ProductA widgets,
  then 'service_a_widgets' will be inserted before 'service_b_widgets'
  on installation, and thus 'service_a_widgets' will be searched before
  'service_b_widgets'.

   This ordering will break, however, as soon as one refreshes
  ProductA but not ProductB, which will remove the widget root of
  ProductA on uninstall and re-add it on install. Afterwards
  'service_a_widgets' occurs later in the list than 'service_b_widgets'.

   A 'refresh all' would fix this, as this installs everything in the
  right order, but this is not very convenient. I could imagine of a lot
  of postings to silva-general saying "my widgets to fail due to strange
  acquisition problems" followed by an "oh, a 'refresh all' fixed it, but
  I do not understand, why .."

 b) A straight forward way to fix this would follow the way the Silva
  product solves the analogous problems for the "view" lookup.
  This would boil down to implementing something similar like Silvas
  ExtensionRegistry. Having some longer thought about it, the result
  seems to look that much similar one could as well copy over the code
  from Silva and adjust it a little.

   I do not like this approach, as it boils down to cut & paste
  programming or something equivalent.

 c) To avoid duplication registration code from Silva to XMLWidgets, one
  could add a dummy "WidgetRootRegistry" to the XMLWidgets, which does
  nearly nothing (e.g. returning 'self.aq_inner.aq_parent' as the only widget root)
  and add a more sophisticated replacement in Silva, which uses the
  ExtensionRegistry available in this product, and implements a more
  sophisticated widget root handling.

   As a result one has an additional level of registration/lookup in the
  XMLWidgets which does not seemingly add much benefit to the product.
  I guess it would work that way, but if someone looks at the XMLWidgets
  without Silva, this person may ask why this seemingly silly additional
  level is implemented there.

   Another drawback of this approach for me is that I cannot see how to
  make the default implementation replaceable, except by placing it in
  the ZODB (similar to Silva service_members, etc); this would mean
  ...

[Clemens Robbenhaar (crobbenhaar)]

Sorry for my last mail -- sometimes writing down things helps ordering
the thoughts, but I did not really need to send there thoughts around
disturbing other people (especially in a quite busy point in time ...)

 I just checked that option "d)" of my last mail works fine, without
touching Silva at all ... I guess I will proceed with this one.

[Clemens Robbenhaar (crobbenhaar)]

As Martijn has factored out the MultiViewRegistry into an own product,
reusing the code there is maybe an option now.

 I do not know if this is planned, but if it is, I could try
to move the "pluggable widgets" into this direction. With the current
state I am not quite sure how to achieve this ... WidgetRegistries
would have to inherit from MultiViewRegistry, it seems.

 Has the refactoring of the SilvaViews product been intentional with this
possiblility in mind, or am I completely abroad?

[Kit Blake (kitblake)]

(Old issue cleanup) I think this is history. if not, we have a mutable tracker.