[Zope3-dev] Content Types: What are they? Do we need them for Zope 3

[Casey Duncan]

On Thursday 14 November 2002 03:15 pm, Jim Fulton wrote:
> Historically, Zope has a notion of "type" that has not been
> very well defined.
>=20
> - Zope 2 has something called "meta type".  This is used for at
>    least two different things in Zope 2:
>=20
>    o As a nice name for an object type (class).
>=20
>    o As a name for constructors in add menus. Note that these were
>      originally intended to be constructors for specific object
>      types, but later they included things like "Zope Search
>      Interface", which didn't build any one specific object type.
>=20
>    In addition, I'm told that Silva selects UI components based om
>    meta type.

I think that we must have some mortal-readable name given to "types". IMO=
, in=20
Zope3 terms a type is described through an interface. Therefore it would =
seem=20
that an "object type" (I hesitate to use the word content here, what abou=
t=20
objects that aren't related to content?) is simply a friendly "display na=
me"=20
for a single interface.

Now, this is quite a different thing from a meta_type. Since meta_types=20
classically denote a single class. As Stephan points out, if we use=20
interfaces to denote types, then an object can be simultaeously an image =
and=20
a file.

This is not a bad thing, except how does one sort objects by type? With=20
explicit being better than implicit I imagine that when registering conte=
nt=20
you should be able to declare a single interface as the "type" of the=20
content. This interface should of course be implemented by the objects=20
created by the factory (this could be enforced by the framework). In a=20
separate declaration, you would specify the friendly name for the interfa=
ce=20
to be read by non-programmers.

For instance:

<type interface=3D".Image.IImage" title=3D"Image" description=3D"An Image=
 File" />

<content class=3D".Image." type=3D".Image.IImage" />
=2E..

Perhaps this could supplant the title and description we currently give t=
o the=20
factory declaration inside content. It seems that the current business of=
=20
declaring it on the factory only helps us in creating objects, not=20
identifying objects that already exist. This could take care of both.

> - The Content Management Framework (CMF) has "portal types".
>    Portal types were orginally meant to be like meta types that
>    could be set on individual instances.  Instances with the same
>    meta type could have different portal types, to reflect
>    different usages of the same underlying implementation.  Also,
>    while Zope meta types are just strings, portal types name
>    objects that provide meta data and functionality.
>=20
>    The CMF uses portal types in a number of ways:
>=20
>    o Portal types allow type-specific configuration. Portal types
>      are used as keys into a variety of registry (or registry-like)
>      mechanisms, including:
>=20
>      - Skins, which associate templates and scripts with portal
>        types to provide custom user interfaces and application logic.
>=20
>      - Workflows
>=20
>      - Actions, which reporesent type-specific applications
>=20
>      In this respect, portal types in the CMF are used the same way
>      that interfaces are used in Zope 3.
>=20
>    o Factories are defined for portal types. There's a one-to-one
>      relation between factory and portal type.
>=20
>    o Portal types have meta data.

I think the above could also take care of this. The idea of types could b=
e=20
extended to include additional metadata. These declarations could be tied=
 to=20
a service for using the metadata in an application.
=20
> I think that many people think of content types as naming
> specific concrete types of objects.  People might expect a
> content-type to include specific information. This makes content
> types a bit more concrete that interfaces.

I agree. In the above, certain interfaces are declared explicitly as "typ=
es".=20
These interfaces would be the ones directly exposed to the end users of t=
he=20
system as an identifier of what the object is and what its direct=20
capabilities are.

-Casey

> Zope 3 has no separate notion of content types.  It does have
> content components.  Zope 3 also has interfaces. Content
> components often implement a number of interfaces. No one
> interface is designated to be the content type, although, in most
> cases, it would be fairly straightforward to do so.
> Content components usually register factories,
> but there's no association between factories and interfaces.
>=20
> Does Zope 3 need a "content type" concept? Is so, what should
> content types be used for?
>=20
> What should content types be used
>=20
> Jim