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

[Bjorn Stabell]

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=3DNone, REQUEST=3DNone):
        ''' '''
        action =3D self.getTypeInfo().getActionById('summary', None)
        func =3D 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=3DNone):
        """List content types which meta_type can be bound to."""
        if meta_type=3D=3DNone: meta_type =3D self.meta_type
        types =3D []
        for ti in self.portal_types.listTypeInfo():
            if ti.content_meta_type =3D=3D meta_type:
                types.append(ti)
        return types

--- in metadata_edit form:

  <th align=3D"right">Dynamic type</th>
  <td><dtml-let my_type=3D"portal_type"
      ><dtml-in listContentTypes>
      <dtml-if sequence-start>
        <select name=3D"portal_type:ignore_empty:ignore_missing">
        <option value=3D"">Please select..</option>
      </dtml-if>
        <option <dtml-if "my_type =3D=3D
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,
--=20
Bjorn

-----Original Message-----
From: Oliver Bleutgen [mailto:myzope@gmx.net]=20
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.
>=20
>=20
> SEVERAL TEMPLATES FOR ONE CONTENT TYPE
>=20
> With the CMF you have another level of typing of objects available:
> portal_type (dynamic type).  A meta_type can have many corresponding=20
> portal_types, e.g., a generic MyDocument class (implemented in a=20
> 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).
>=20
> 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=20
> object, I scan the available portal_types for the given meta_type and=20
> 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=20
> selecting the correct skins to use (based on the portal_type=20
> 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


=20