[Zope3-Users] Re: Get classes implementing Interface

[Jeff Shell]

On 12/30/05, Florian Lindner <mailinglists at xgm.de> wrote:
> Am Freitag, 30. Dezember 2005 17:45 schrieb Jim Fulton:
> > Philipp von Weitershausen wrote:
> > > So, what you want is not a list of classes but a list of factories that
> > > can create IContainers. This is possible by using
> > > zapi.getUtilitiesFor(IFactory) and then checking each factory's
> > > getInterfaces() method whether IContainer is a part of the returned
> > > result. I would probably base an implementation of all on the
> > > UtilityVocabulary.
> >
> > I'll also note that the use case is also directly addressed through
> > containment constraints.  You can say that a container
> > should only contain objects of some given types and you will get
> > just those types in the add list.
>
> But the HomeFolderManager is not a container itself it's just a utility that
> creates container upon requests. And I want to make choosable which container
> to create. Or do I misunderstand you?

Well first (and I apologize if this has been mentioned before),
'containers' are a more abstract notion while 'folders' are more
concrete. A message or document that allows comments might be a
container, but it's not something that you'd see in the ZMI or any
content management type interface as a folder. You'd see it as an
article.

Something that's "Folderish" (to drag up an old term) will probably
have a folder icon, will probably (but not necessarily) will have
sub-folders, will have a view to manage its contents, and so on.

It's important to keep these concepts distinct. In our content
management system, we have a lot of containers. Due to a lack of
understanding on my part about when I really wanted a generic
container versus when I wanted a folder, we had some behavioral issues
in our code at times because generic views were being applied to the
wrong thing. During a big refactoring sweep I just completed, I
separated these concerns completely and made a specific marker
interface, 'IFolderishContainer' (ahh, memories again of
_isPrincipiaFolderish ;) that classes or interfaces had to
_explicitly_ declare support for. I made the common Folder class that
we were using taboo for subclassing unless one really meant to take on
all of the responsibilities of that Folder (user interface support for
reordering, navigation menu building, and so on). And that folder
class, itself, does not subclass from zope.app.folder.Folder since I
didn't want these folders to be potential site managers.

So then a photo gallery or jobs folder would just declare support for
that interface, typically in ZCML. Then they could selectively choose
what other capabilities they wanted. And that's how we separate
Folders from other kinds of Containers.

I think that was some of the earlier questions in this thread - how to
tell if a container is really folderish versus a more generic
container. In the closed world of our custom applications, this is how
I solved the problem after some painful lessons along the way.

Using marker interfaces like this has been awfully helpful. I use it
in another situation where I have a single "addMenuItem" item that
uses a view that lists all factories that declare support for a couple
of specific interfaces. Something like this could probably help you
too if this is what you mean by providing a choice as to what folders
/ containers can be created. This provides data to a template via the
'addableContainers' method which just looks for factories for the
IHomeFolderableContainer faux interface I made up here.