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:[EMAIL PROTECTED]]
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
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
