Re: RFC: Proposal Dexterity API - two variants

Martin Aspeli wrote:
> Here are two scenarios that are supported (or at least were considered
> in the design):
>
>  1) The behaviour provides a collection of fields and those are
> "normal" fields that your type has. It should use the 'provides'
> registration that means the behaviour interface is directly provided
> by the content object. Access to the field is via standard attribute
> access. You can choose to use a IMyBehavior.providedBy(context) check
> if you wish, or even a null-adapter IMyBehavior(context) adaptation if
> you so choose, but you have the attribute access semantics you want.
>
>  2) The behaviour provides some kind of complex logic. Versioning.
> Audit logging. Whatever. It should use a standard registration that
> means you have to adapt to it. It may include some fields, but it will
> be responsible for deciding where they're stored. Possibly on the
> content object, possibly somewhere else. The main consumer of this
> will be some other code probably written in the same package, e.g. an
> event handler or a viewlet or a view, and in this special reusable
> advanced code, you adapt the context to your interface so you can
> operate on it.
>
> I think the problem here is that we may have accidentally had a use
> case for scenario 1 that was implemented like scenario 2. That's
> pretty easy to fix.

+1

AFAIK, only more like 2) is the event behavior with its dates. Johannes
knows its details. It's designed to enforce timezone aware values, but
nobody seem to know, how to do it properly (because values also depend
on "whole day" and "open end" flags).

-Asko

------------------------------------------------------------------------------