[Zope-dev] Different way to use portal_types actions (was: Best way to do "links")

29 Nov 2001

      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