On 12/30/05, Florian Lindner <[EMAIL PROTECTED]> 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. _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users