Re: RFC: Proposal Dexterity API - two variants

Hi,

On 5 November 2014 20:56, Johannes Raggam <[email protected]> wrote:

>
> First time, when I encountered behaviors some years ago, I really
> disliked the need to adapt a context to the behavior interface in order
> to get or set attributes to it.
>

You only need to do that if the behaviour is built to make you do that. ;)

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.

I think we may also have just gone a bit overboard on
reusability/configurability by having really fine grained behaviours in
some places, which adds complexity that probably isn't warranted and would
be better in my opinion to turn into fewer more coarse grained behaviours
to reduce cognitive load.

Martin

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

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers