[Zope-CMF] child class behaves like PortalFolder

[Tres Seaver]

On Sun, 24 Mar 2002, Jens Wolk wrote:

> Am Mittwoch, 20. M=E4rz 2002 15:31 schrieb Tres Seaver:
> > Jens Wolk wrote:
> > > Am Mittwoch, 20. M=E4rz 2002 13:28 schrieben Sie:
> > >
> > > [...]
> > >
> > >> > However, my folderish "CMF zyp Category" behaves like it was a
> > >> > PortalFolder (its parent class) and I don't know why. (If I - fo=
r
> > >> > example - click on "Edit" for the object myZypCategory then
> > >> > myZypCategory/folder_edit_form is called instead of
> > >> > myZypCategory/zyp_category_edit_form)
>=20
> [...]
>=20
> > Somehow the 'portal_type' of your instances is not being set;
> > are you creating them via the stock 'folder_factories' form?
> > Or are these objects created by some other process? =20
>=20
> I'm not sure if I understand the question correctly. I create the insta=
nces=20
> through the ZMI (or the "folder contents" view of the folder in which t=
he=20
> instances are located), so this means, they are created by the=20
> 'folder_factories' form, right?

The ZMI and the "CMI" (CMF 'folder_contents' view) aren't
identical; in particular, creating a piece of content via the ZMI
is likely to lead precisely to the condition I described
('portal_type' not set).  The "New" button of the CMF
folder_contents view invokes the 'folder_factories' view, which
in turn posts to 'invokeFactory' of its container;
'invokeFactory' *does* set the 'portal_type' correctly.

The "Add list" of the ZMI is an older mechanism, which doesn't
know about the CMF's "type" machinery;  it presumes that all
instances of the same class are of the same "kind" (which is
not true for CMF content).

> Creating by another process would for example=20
> mean in a Python script, is that so?
>=20
> > As a check,
> > use your browser to call the 'Type' method of one of your objects
> > (i.e., append '/Type' to the URL):  I am sure it will return "Folder".
>=20
> Correct.
>=20
> > If you aren't constructing instances of your type via 'invokeFactory'
> > on its container, then you likely need to mimic what it does;  in
> > particular, you will need to call '_setPortalTypeName' on the new
> > instance.  If you don't intend for your class ever to be used as a
> > base for more than one type, you could also add a shared attribute,
> > 'portal_type', to the class, e.g.::
> >
> >    class zypCategory (PortalFolder, DefaultDublinCoreImpl):
> >        """
> >        a zyp category
> >        """
> >
> >        meta_type =3D 'CMF zyp Category'
> >        portal_type =3D 'zypCategory'
> >        #...
>=20
> This solution works. There seems to be another solution which I saw in =
the=20
> "CMFArticle" product (call manage_afterAdd of parent class PortalFolder=
).
>=20
>     class zypCategory (PortalFolder, DefaultDublinCoreImpl):
>         """
>         a zyp category
>         """
>=20
>         meta_type =3D 'CMF zyp Category'
>         #...
> =09
> 	security.declarePrivate('manage_afterAdd')
> 	def manage_afterAdd(self, item, container):
> 		" Add self to the workflow and catalog. "
> 		# Recurse in the children (ObjectManager)
> 		PortalFolder.manage_afterAdd(self, item, container)
> =09
> 	#...
>=20
> That way it should still be possible to use the zypCategory class as ba=
se=20
> class for other classes, shouldn't it?

'manage_afterAdd' by itself *would* serve to get your content
catalogued;  it would *not* invoke the correct workflow, because
the 'portal_type' still won't be set correctly.  You *must*
arrange to get that set somehow, either by setting it in the
class (which reduces flexibility), or by creating the intsance
via 'invokeFactory' (the normal means), or by calling
'_setPortalTypeName' yourself.

> With CMF and Zope, I feel more or less like a coding monkey: copying co=
de=20
> from others without understanding what's going on behind the scenes :-/=
=20
>=20
> But with the encouraging support like yours, Tres, this situation will=20
> hopefully soon improve. :)

Neither framework is perfect, and the CMF in particular is
(woefully) underdocumented, outside the source.  Documenting
software is hard, at least in part because many of the rewards
of the act are directed away from the actor, unlike the
production of working code.

Tres.
--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.org