Document Actions
Zope 3 Design Pattern Questions
Here I will gather questions I have about certain design patterns in Zope 3, as well as answers to them whenever I happen to get answers. If you can explain the answer to this question, please send me an email at paulcarduner@gmail.com
Pattern for Containers
Containers are an integral part of any Zope 3 application. In general, the pattern for creating containers and the stuff that goes inside them consists of three key interfaces: IObject, IObjectContainer, and IObjectContained (notice the last letter). IObject simply has whatever schema you want, but the importance of IObjectContainer and IObjectContained is the constraints placed on them. You have one constraint that says IObjectContainer can only contain things that provide IObject. You also say that IObjectContained can only be contained by IObjectContainer. Now, my real question has to do with the implementation of these. I have never seen IObjectContained implemented separately from IObject. Usually in the implementation we have a line like:
implements(IObject, IObjectContained)My question is, should the implementation of IObject really provide the IObjectContained interface as well? It seems that IObjectContained is really only a marker interface that specifies a constraint, which is not an integral part of the nature of IObject (otherwise we would have put the constraint in IObject and not IObjectContained). That said, wouldn't it be better to register IObjectContained as being provided by the implementation in zcml? What is the standard practice for this?
-
This pattern depends on the scope of your project. If you are making a pure Zope 3 application (one where code won't be used in non-zope environments) then it is fine to have implementations directly provide IObjectContained. Afterall, this is an integral part of the object from the Zope point of view. However, if you plan on using this code outside of Zope then it is better to provide a separate implementation of IObjectContained.
Thank you Stephan Richter (paraphrased).
Menu Madness
This is a fairly simple question. When creating new Zope components that are meant to be one object in a zope instance, we often want to create our own skin. It is common to want some kind of menu showing different viewing options for a given object in your component (view, edit, etc.) If we didn't have our own skin, we would just register these menu items with the zmi_views menu. However, when creating your own skin, is it better to reuse zmi_views or create your own menu? The following are some pros/cons I have come up with.
In any case, my guess is that it is better to just reuse zmi_views until your application gets big enough that you are customizing *all* the views you would normally see in Rotterdam (and thus with the zmi_views menu).Pros Cons - There are already some standard views for containers that register menu items with zmi_views (like the Contents view).
- The metadata tab is already registered for zmi_views.
- You don't have to make multiple registrations to have menu items show up both in your skin and in the Rotterdam skin. (In the event that a more savvy user wants to use Rotterdam).
- When you reuse bread crumbs, the link provided by each item in the breadcrumb is to the @@SelectedManagementView.html view of the object. This view redirects to the first available view registered with zmi_views. To get around this you would have to reimplement breadcrumbs or zope.app.publisher.browser. managementviewselector.ManagementViewSelector
- You can get rid of the Introspector tab which will probably just confuse the heck out of the end user.
Dublin Core
Zope's Dublin Core seems to be very versatile and very useful. For example, nearly every content object in an content management system should have a title, and often even a description. These are easily handled with the Dublin Core metadata model. However, for a lot of these objects I want a title to be a mandatory attribute that the user *must* specify. Naturally I would think to do this with schema fields and auto generated forms. Unfortunately, there doesn't seem to be a way to attach Dublin Core stuff to auto generated forms, and force the user to specify metadata. It would seem that you have to use your own title and description attributes in the schemas for all your objects. This is fine except that certain default zope views (like @@contents.html) use the Dubline Core to get metadata like the Title of an object. But if it is not specified in the Dublin Core, (since it is specified as an attribute of the object), then nothing will be displayed for the title?
In any case, how can I better integrate the Dublin Core into my content components. I want metadata to be required, and displayed in auto generated add/edit forms. Not just so I can reuse preexisting views like @@contents.html, but also to reap all the benefits of metadata (as far as the transfer of information goes).