Re: RFC: Proposal Dexterity API - two variants

On Thu, 2014-11-06 at 09:48 +0200, Asko Soukka wrote:
> 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).

yep. that's a pain. there is a event subscriber listening for the object
modification event, which sets start/end dates according to
timezone/whole day/open end. too much magic, you have to fire the event
manually when doing it programmatically. maybe it can be solved by doing
the whole day/open end manipulation client side via a new mockup
pattern.


> 
> -Asko

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

_______________________________________________
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

iEYEABECAAYFAlRbOxcACgkQW4mNMQxDgAekMwCglNyIVt643APLNcFFXivTSV/2
Mc8An1U7fPocoElagXkd8cb/NSls7t6d
=tsj3
-----END PGP SIGNATURE-----