Re: RFC: Proposal Dexterity API - two variants

On Wed, 2014-11-05 at 22:46 +0000, Martin Aspeli wrote:
> 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. ;)

I know... that was only the introduction to my lengthy mail before ;)

> 
> 
> 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

-- 
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
plone framework  team  member
mail: office-//[email protected]
web:  http://programmatic.pro
      http://bluedynamics.com

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlRbLyIACgkQW4mNMQxDgAfqgACgraTCJdNOrIMl/Mc2SgWjThqd
3CMAn0hEyn1A5rsVCttl64VcLaQq3Dvz
=EQ89
-----END PGP SIGNATURE-----