clean out ZMI add object list

[Christian Zagrodnick]

The ZMI add object list is filled with all sorts of silva objects, which doesn't
seem to be necessary. There are ways of filtering it.

[Kit Blake (kitblake)]

Please!

[Andy Altepeter (aaltepet)]

Here's the scoop. It is possible to filter out objects, by setting "visibility=None" in registerClass (zope's method, not Silva's). The problem here is that items are now filtered out for any call to context.all_meta_types(). The only place where this method is called in Silva is in ViewCode.render_icon_by_meta_type.

It is possible to get Silva objects back into all_meta_types, by calling the method with the parameter interfaces=[ISilvaObject].

So, by setting visibility=None when calling registerClass, and by changing any all_meta_types calls in Silva to use the interfaces parameter, I think we'd cover most cases. Note that this doesn't hide non-SMI objects from the ZMI add list! But, what if an extension wants (or should) have SMI objects in the ZMI add list? (see below)

But, there is a bug in zcml/handlers that doesn't add all interfaces to content types registered through zcml. I have an uncommitted fix for that.

So, I recommend the following:
1) By default, all registered SMI objects are hidden from the ZMI add list. ExtensionRegistry and zcml/handlers need to be updated to cover this
2) Viewcode is updated to limit to ISilvaObject implementors
3) Silva zcml IContentDirectory has an additional attribute, visibility, that allows extensions to turn on the ZMI add list for a specific SMI object. IVersionedContentDirectory should have a similar attribute for the version_visibility. I can image a case where, e.g. Silva Documents shouldn't be added through the SMI, but SilvaDocumentVersions could be (or vice-versa).
4) All known infrae-based extensions should be grepped to see if they call all_meta_types. It is possible SilvaNews does.

So, let me know how / if you want to proceed down this path. I would plan this as a 2.1 feature.

[Kit Blake (kitblake)]

This sounds fine. We'll have to be communicate this to developers, but if they don't listen, their objects will show up in the ZMI add list. But it's really for a first-time Silva install that I want this. Too many people add things that shouldn't be added. Also, it's annoying to scroll through an enormous list is things that shouldn't be added, looking for something that should, like a Silva Code Source.

We'll have to think about the name of the zcml attribute. 'visibility' is overused and we probably should be more explicit, 'zmi-addable' or something.

[Andy Altepeter (aaltepet)]

I noticed that this broke copysupport, so I had to disable it for now.

[Andy Altepeter (aaltepet)]

I've checked in a potential solution, in a branch here:
https://svn.infrae.com/Silva/branch/aaltepet/Silva-zmi-add-filter-100670
https://viewvc.infrae.com/svn/Silva/branch/aaltepet/Silva-zmi-add-filter-100670/

[Kit Blake (kitblake)]

One detail which may or may not apply, since you mentioned ViewCode.render_icon_by_meta_type. I'm planning a small refactoring of many of the templates. Most of them define an icon with: python:view.render_icon(model); but since almost all templates do it, I'm planning to move it into the macro_index. This was waiting for a change in that method which is now done, I just haven't made the time to do it.

[Andy Altepeter (aaltepet)]

Good to note. I don't think that this zmi add filter will affect the potential solution I checked in, which happens to be a bit different from what I've described above.

I've put a description of how the zmi add filter works in doc/developer_notes.txt in this branch.