Re: API for setting/getting values on Dexterity content

Hi Robert,

Robert Niederreiter wrote:
> 
> 
> Hi Andreas,
> 
> Am 2014-10-22 um 12:39 schrieb Andreas Jung:
>> Perhaps you did not read my blog posts or you did not got my point.
>>
>> The developer experience with Plone and Dexerity - if done the
>> right way - is horrible. As developer right now I have to know
>> which behavior implements which field in order to set/get
>> a value the right way.
> which is actually a good thing if a developer knows how data entities 
> are built ;).
> 
> I think that the knowledge of the existing behaviors is moslty a 
> documentation issue.
> 
> But i agree, the need to understand an adapter in order to to set an 
> object's value might confuse non zopers.
> 
> And maybe a string identified behavior fetching function might help. And 
> for debugging purposes a function listing behaviors and behavior 
> attributes of a type.

I like that idea. That's the same principle we use with grouped forms
(z3c.form) were we use a prefix to distinguish between different fields
(with maybe the same id) in different fieldsets/groups. Accessing
behaviors could be the same. IMHO access to behavior attributes should
only be possible using a 'prefix'. And so direct access to attributes
should only be possible for schema fields.

So setting/getting a schema value could be (based on Andreas' suggestion):
plone.api.content.set_value(obj, fieldname,  value,
behavior='behavior_name')
value = plone.api.content.get_value(obj, fieldname,
behavior='behavior_name')

Same for Dexterity base classes:
obj.set_value(fieldname, value, behavior='behavior_name')
value = obj.get_value(fieldname, behavior='behavior_name')

Without a provided behavior argument the schema attributes should be
processed. Now the question is how an AttributeError should be handled
when trying to access a behavior attribute on the schema level. Should
the AttributeError be raised? Should we try to return a value from a
default behavior with the matching name?

Thomas


> 
> It would hide the ZCA a little bit and debugging would be a lot easier. 
> Consider the following example
> 
>     >>> obj.behaviors
>     basic
>         title
>         description
>     publication
>         effective
>         expires
> 
>     >>> basic = obj.behavior('basic')
>     >>> IBasic.providedBy(basic)
>     True
> 
>     >>> basic.title = u'Foo'
>     >>> basic.title = u'Bar'
> 
>>   It is horrible because as a developer
>> I want to write pythonic code (translates to attribute access).
>> This was also one of the design goals and promises of Dexterity
>> as far as I recall. But reality is different. Everyone one write
>> Pythonic code but the code is potentially broken (see my rants
>> about the plone.app.event implementation).
> Potentially broken when expecting data entity values must be settable 
> directly, yes.
>> So the idea - or better the necessity - is to give developers
>> a consistent way to read/set values. This means in the first place that
>> the whole behavior stuff should be hidden from the developer - at least
>> for the standard developer which average skills who is the potential
>> user of plone.api. As a developer (e.g. in my current role as writer
>> of a fat migration process) I want assign values to an object without
>> checking other peoples source code about where a particular attribute
>> is defined and check for the related interface. This complexity must be
>> hidden in order to writer code in more clear way, in a more reliable way
>> and in a more readable way.
> This sounds much like the view out of a migration process rather than 
> from daily development tasks. The stregth and the weakness at the same 
> time is the use of behaviors for building types. The benefit is a 
> reusable set of behaviors, the weakness the need of understanding the 
> concept and it's API (ZCA right now).
>> The implementation of set/get methods must perform some kind of
>> introspection on the schema and the attached behaviors in order
>> to retrieve the related interface for adopting the current context
>> object. This is of course in some way slower that direct attribute
>> access but it is the right way. There is certainly a performance loss
>> with this approach but I guess that this could be minimized with
>> clever caching of the schema introspection results.
> We can also just delete dexterity and start reusing archetypes.
> 
> Seriously, i agree with having such a javaic (analog to pythonic) API 
> would be a convenient thing for beginners (or trivia tasks) - but 
> nothing more.
> 
> Or you just go ahead and teach people to avoid default behaviors, and 
> write every type from scratch using schema classes only (no behaviors at 
> all) and corresponding content classes. And create building blocks using 
> inheritance.
> 
> https://github.com/collective/transmogrify.dexterity/blob/master/transmogrify/dexterity/schemaupdater.py
> could be a starting point for a getter/setter API
> 
> robert
>> -aj
>>
>> Roel Bruggink wrote:
>>> Hi Andreas,
>>>
>>> I get what you say. I have a few questions on how this would work in
>>> practice, though.
>>>
>>> Assuming the following:
>>> IMySchema():
>>> start
>>> end
>>> name
>>> animal_type default='Känguru'
>>>
>>> IMyFirstBehavior():
>>>   start
>>>   end
>>>   lives_in default='Känguru Island'
>>>
>>>   IMySecondBehavior():
>>>   name default='Jos Henken'
>>>
>>> How should set_value('start', now()) and get_value('start') behave?
>>>
>>> Would a dict-like api be of more use, ie obj['IMyBehavior.fieldname'] =
>>> 'new value' ? We'll still probably have to adapt the object to that api,
>>> though.
>>>
>>> So in the end, direct attribute access for just the schema itself would
>>> work, unless the fieldname is unique between all behaviors.
>>>
>>> -Roel
>>>
>>> On 22 October 2014 10:25, Andreas Jung
>>> <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>      Hi there,
>>>
>>>      the following suggestion is based on former blog posts of mine, e.g.
>>>
>>>      https://www.andreas-jung.com/contents/bad-dexterity-application-design
>>>      https://www.andreas-jung.com/contents/copying-dexterity-fields-from-one-instance-to-another-instance
>>>
>>>      I clearly see a need for an API for safely setting and getting values
>>>      for Dexerity content that takes all aspects of behaviors into account.
>>>      In general: direct attribute access to on Dexterity instance was a nice
>>>      goal but in reality it is a broken and dangerous programming pattern in
>>>      Plone right now - unless the direct getting/setting of values through
>>>      direct attribute access can be fixed somehow (I think this is very
>>>      hard).
>>>
>>>      The safest way would be to provide methods like
>>>
>>>      plone.api.content.set_value(obj, fieldname,  value)
>>>      value = plone.api.content.get_value(obj, fieldname)
>>>
>>>      as part of plone.api or through methods of the Dexterity base
>>>      classes Item and Container:
>>>
>>>      obj.set_value(fieldname, value)
>>>      value = obj.get_value(fieldname).
>>>
>>>      The method names are dust and smoke and could be named differently.
>>>
>>>      Any thoughts on the need for encapsulating the setting/getting of value?
>>>      Any thoughts where such an API would fit best (plone.api vs. base
>>>      classes)?
>>>
>>>      -aj
>>>
>>>
>>>
>>>      ------------------------------------------------------------------------------
>>>      Comprehensive Server Monitoring with Site24x7.
>>>      Monitor 10 servers for $9/Month.
>>>      Get alerted through email, SMS, voice calls or mobile push
>>>      notifications.
>>>      Take corrective actions from your mobile device.
>>>      http://p.sf.net/sfu/Zoho
>>>      _______________________________________________
>>>      Plone-developers mailing list
>>>      Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>>      <mailto:Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
>>>      https://lists.sourceforge.net/lists/listinfo/plone-developers
>>>
>>>
>>>
>>>
>>> -- 
>>> Roel Bruggink
>>> http://www.fourdigits.nl/mensen/roel-bruggink
>>>
>>> Four Digits BV
>>> http://www.fourdigits.nl <http://www.fourdigits.nl/> tel: +31(0)26 4422700
>>>
>>> ------------------------------------------------------------------------------
>>> Comprehensive Server Monitoring with Site24x7.
>>> Monitor 10 servers for $9/Month.
>>> Get alerted through email, SMS, voice calls or mobile push notifications.
>>> Take corrective actions from your mobile device.
>>> http://p.sf.net/sfu/Zoho
>>>
>>> _______________________________________________
>>> Plone-developers mailing list
>>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for $9/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> Plone-developers mailing list
>> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Plone-developers mailing list
> Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJUR51zAAoJEI51/d0jlpyM0GUP/iJbgzRU7RcWbP2IIVxs6mV6
reocq0E1Hvy3wpSIUSqpkebJqtHU74X6jidFTlE59l4wR9VU3sy8L50XoxSRbKOf
eH5ebBa6YNCUv6nothGFdcBgp61ORisU/cfImz6q2vdyFThwGt/T7PL0A0cwtAB4
Gm+/G5n3bfH1T0nVv+K00c6FYQCaqGBpoHjvWe0tesEEAiRIT4v5JBKWU+5p2NDq
eEt4W++9Dc89cl5+rVrmjG7EI3BsGLPNtUnAZ6IBy7imN0JQR8n7RZZGoS93qtsz
Y/hfIJWn+HPVl8s5U7Wdv3BOzXpP30zitU0Nunp00ch7aKkTAIsWtWwf+rGaWTig
bIbJPWDE3fq+WMlDNU7UC9C5CetrSMRMDEx6shulZ2rSiPc2FhLVpiZ5d4UNyHiK
/3EcmFV7be3jxDw2IC93fCez24MiLocA4Nj8lENkJ7TFal1aBn5Nw6M3wrGB615C
Fck/n/IGCB1Budg+m6nS7pQjZZkDkrEJFfFmLmarK/04Rs91QpytX/fPNleu77I9
UoLf5R/Cx6Pxp1ioMcV9WUwRcdPjd3a6fzw9iWY/adwWbIxZplVHplSVEMqnwOOE
IOMIngbJbuIT7otPq0FDIUOGm5znubSZiii5zk+nMjGPe3xKzL1aEpnBqZ2BqNXt
a3KTRVwBwkyC4yxoEf72
=lR/4
-----END PGP SIGNATURE-----