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

[Martijn Faassen]

Jim Fulton wrote:
> Historically, Zope has a notion of "type" that has not been
> very well defined.
> 
> - Zope 2 has something called "meta type".  This is used for at
>   least two different things in Zope 2:
[snip]
>   In addition, I'm told that Silva selects UI components based om
>   meta type.

That's correct. You can register views for a meta_type (add view,
edit view, public view); these views have various methods,
mostly page templates and python scripts.

[snip]
> Does Zope 3 need a "content type" concept? Is so, what should
> content types be used for?

* determining what's in any add list. I'd propose we go back to the
  original idea of Zope 3: nothing should occur in the
  add list that does not add one specific object; for any other
  actions we should be doing something else. We will be providing
  a separate list for such actions.

  But even if this is not directly reflected into the UI, we need
  such a separation of concerns internally.

  By itself knowing which content types exist is not enough to
  determine what should be in the add list; there is commonly
  a subset. In the content part of the tree, you'd get only
  content related objecs. In the service managers there may
  be an entirely different set of objects addable, though there
  may be some overlap as well. The word 'content' is potentially
  confusing here as we're sometimes talking about software.

* An object that is of a content type needs some standard set of meta data;
  the meta data can then be counted on in the user interface;
  I'm thinking of such things as 'title' and 'description';
  Dublin Core stuff. This is the same as saying all content types
  should implement some minimal interface/can be adapted to a minimal
  interface.

* A content type by itself may also need some meta information,
  though in part that is taken care of by being of an interface.
  I can also imagine 'addability' could be determined by interface
  information; perhaps an object that should be addable to the
  FooServiceManager container needs to implement IAmAddableToFoo :)
  Do I have to specify such interface then to make it addable
  at all, in addition to making the object implement the content
  type interface? Or is there some other, better way to solve this?

  Lots of the 'meta data' we may consider hooking up to 
  content types is already taken care of by the component 
  architecture and having an interface; views and adapters and such.

  Can all conceivable content type meta data be similarily absorbed away 
  by the component architecture or is any left that cannot be?

* An object that is of a content type will appear in a certain way 
  in the folder hierarchy. Will it be possible for non-content type
  objects to be visible in the folder hierarchy in the same way?

* Content types will have a URL. The URL should in some way be
  discoverable. Can non-content types have a url as well? 
  I imagine so, but we may have less introspection/discovery 
  guarantees for them?

Anyway, random thoughts mostly..

Regards,

Martijn