Re: API for setting/getting values on Dexterity content

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.

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
>>      [email protected]
>>      <mailto:[email protected]>
>>      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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/plone-developers