Oliver, Yes, you're right there is no direct link; I forgot to mention that. I've made the link similarly to the way 'index_html' and 'view' are linked by looking up in portal_types the Type object corresponding to your portal_type. Here is an example: security.declareProtected(View, 'summary') def summary(self, client=None, REQUEST=None): ''' ''' action = self.getTypeInfo().getActionById('summary', None) func = getattr(self, action) return func(self, client, REQUEST) So you basically have to designate a few methods that you want to override this way. This wasn't a big problem for us. We basically subclass all our content from a base class that defines these methods in the same way as summary was defined above, effectively letting us override them in dynamic types: line - a line based rendering of the content, suitable to use in listings feature - a half-page width render if the content, with icon image, title and description summary - a one-paragraph rendering of the content, suitable for inclusion in search results body - just the body of the content, suitable for inclusion in other templates Furthermore, we've extended the metadata_edit form so that it shows a pull-down menu of all portal_types that can be used with this meta_type, also found dynamically by looking it up in portal_types: -- in base class: def listContentTypes(self, meta_type=None): """List content types which meta_type can be bound to.""" if meta_type==None: meta_type = self.meta_type types = [] for ti in self.portal_types.listTypeInfo(): if ti.content_meta_type == meta_type: types.append(ti) return types --- in metadata_edit form: <th align="right">Dynamic type</th> <td><dtml-let my_type="portal_type" ><dtml-in listContentTypes> <dtml-if sequence-start> <select name="portal_type:ignore_empty:ignore_missing"> <option value="">Please select..</option> </dtml-if> <option <dtml-if "my_type == id">selected</dtml-if>>&dtml-id;</option> <dtml-if sequence-end> </select> </dtml-if> <dtml-else> No dynamic types available for &dtml-meta_type; </dtml-in> </dtml-let> </td> --- In a way, this is abusing the actions of the portal_types. This is not a problem for us as we don't use them: we find just providing a "Manage" link to ./manage_workspace to work better, and then creating all our management interfaces in the ZMI... It is more reusable this way, and provides content managers with more power. Bye, -- Bjorn -----Original Message----- From: Oliver Bleutgen [mailto:myzope@gmx.net] Sent: Thursday, November 29, 2001 00:23 To: Bjorn Stabell Subject: Re: [Zope-dev] Repost to zope-dev: Best way to do "links" Hi Bjorn, sorry for adressing you directly, but I have only one small question on what you wrote. Bjorn Stabell wrote:

Two comments. One with regards to solving the original problem, one with regards to links.

SEVERAL TEMPLATES FOR ONE CONTENT TYPE

With the CMF you have another level of typing of objects available: portal_type (dynamic type). A meta_type can have many corresponding portal_types, e.g., a generic MyDocument class (implemented in a Python product) can support many logical types who only varies in their usage and skin. The CMF lets you set the portal_type at creation time (you're basically creating a portal_type object, implicitly based on some kind of meta_type object).

What I'm doing now, and it works quite nicely, is to enable users to change the portal_type at run-time. In the Metadata edit view for an object, I scan the available portal_types for the given meta_type and give the user the option to select one of them as the "current dynamic

type (portal_type). The CMF's portal_skin tool does the rest of selecting the correct skins to use (based on the portal_type attribute).

I don't understand the last sentence, because I don't see any direct link from portal_type to portal_skin. As far as I see it, you get the functionality of dynamic templates by creating objects of differing portal-type, but from the same meta_type, and then using different methods for the view action of each portal_type. I just don't see how the portal_type directly influences the skin which is used to render it. Did I misunderstand you? cheers, oliver