Comment 4 for bug 100213

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
  all widget registries have to access this object somehow, most
  probably by expecting it has a certain Id. This does not look like a
  good idea to me.

 d) Another approach would be to register the wanted roots in the
  WidgetRegistries itself. A product would have full control about in
  which order its widget registries traverse the available widget
  roots.

  This would add some redundant information, as most probably all widget
  registries in one product will want to add the same sequence of widget
  roots.
  There is also a technical complication as the EditorService does some
  widget lookup by itself e.g. when switching to edit mode. I guess this
  is solvable, however.

  I like this approach as it is more explicit and straight forward.

  Some drawbacks are that adapting the Silva code to the pluggable
  widgets is more than an one liner (all widget registry configuration
  needs to be touched, instead of registering the 'service_widgets' root
  once.)
    Hm, on second thought they do not need to be touched at all,
  as they do not need the widget root traversal. A widget registry
  without widget roots could just behave as it did anyway ...

  Additionally in the above scenario with ProductA and ProductB,
  ProductB needs to know that the widget root of ProductA is
  'service_a_widgets'. However if reusing the widgets from ProductA it
  does some more implicit assumptions on the widget structure anyway, I
  guess.

In all the above alternatives I move away from the idea of changing
'service_widgets' to be the common widget folder containing a directory
view for each product.
  This works well for Silva organizing the pluggable views, as there is
only one central view registry, which contains a hard coded
'service_views' to look up before traversing through different
products. In case of the XMLWidgets there are a lot of registries, which
would all need to be told the common "first step" before starting the
widget root traversal. This looks quite uncommon to me.

 On the other hand the widget registries of every new product have to be
placed in the Silva Root anyway, as otherwise they will not be found by
the EditorService (and some helper scripts relying on the
'request.wr_name' attribute).
 Thus adding a new product may add some (or quite a lot)
"service_"-something's to the Silva root; I do not think an additional
directly view will hurt a lot.

 However I admit the views and widgets will be organized somewhat
different, which does not look convenient, especially for a new user.

 Sorry for the long mail; I hope someone somewhen finds the time to read
it and maybe even add a comment about it.