Lennart Regebro wrote:
On 9/29/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
You want to stick this interface to individual objects,
while Lennart proposed to stick it to a type and use
some kind of inheritance to make it effective on all objects
instantiated from this type.
For me, Lennart's approach seems to be far more economic, as
he does things on an abstract (the type) level rather than
always work on the concrete (the individual object) level.
In fact it is absolutely necessary, as you want to be able to change
the behaviour of a whole type of content classes. If you create the
content class "Events" and then suddenly want all events to have a
iCal export support, you do not want to enable this per event, but for
the type "event".
That doesn't make it necessary. Let's say all event objects are marked
with IEvent. Now you want to add behaviour to events. You can do that by
registering stuff for IEvent. All objects marked with IEvent will get
the new behaviour.
Why would a type be needed?
The type is thusly equivalent to portal types of CMF.
Types in Zope 3 are typically expressed by interfaces. I think all of
your use cases can be covered with just interfaces. No need to invent
yet another thing that you'll have to persist and create machinery for.
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
