FYI: Dexterity behaviors and (direct) attribute access explained

jensens · June 24, 2015, 10:19am

For some reason in yesterdays framework-team (FWT) meeting we had some confusion about direct attribute access in context of behaviors. So if the FWT-members are confused, what about all the poor add-on developers out there...

I try to reduce the amount of myths and put in some facts:

First we have two kinds of behaviors:

with schema only (usually a form-field-provider)
with adapter factory

(further reading: plone.behavior README.rst, all, but focus on examples zcml-reference part)

In case (1) schema only all form fields will be store directly on the context.

This has advantages

get values by direct attribute access on context
default values are provided on attribute access too
fast access if value is already set
one does not need to know name of provided interface/schema

and disadvantages:

no name-spaces: if two behaviors are sharing an attribute it is kind of black-magic what happens (however: first wins)
slow access of default: in code it iterates over all behaviors, inspect schemas and then returns default. this probably slows down access in acquisition chains (needs profiling to get numbers).

in case (2) with adapter factory there is no attribute access provided.

Adapters are used if the values need more love than just storing them, also a behavior may read values form a different place or just provides calculations.

So the lookup of the behavior need to be done with the given provides (in zcml) interface/schema. Alternatively a lookup by dotted name (identifier - also provides in zcml) is possible, even if this is not very easy in code.

Btw.: This works also with example (1) schema-only, because the context itself is returned if no factory is given.

In any way one must know the complex dotted name in order to import or resolve, example:

from collective.whatever.module.behaviors import ISomeCustomBehavior
... 
behavior_adapter = ISomeCustomBehavior(context)
value = behavior_adapter.someattribute

advantages:

very explicit
no name-space collisions

disadvantages

need to proxy all attributes to storage (on context)
loooong names to remember
nearly impossible to quickly introspect in debugger
access slower (lookup needed always)

fulv · June 24, 2015, 9:18pm

Shouldn't that be

behavior_adapter = ISomeCustomBehavior(context)    
value = behavior_adapter.someattribute

?

smcmahon · June 25, 2015, 12:31am

To me, the most important message is that if you're writing a behavior that you want to be generally useful, you need to document your attribute access.

djay · June 25, 2015, 12:54am

And how does this work with ttw code?

zopyx · June 25, 2015, 3:28am

That's why the Dexterity programming model is broken by design.

https://www.andreas-jung.com/contents/plone-the-broken-parts-non-pythonic-programming-model

jensens · June 25, 2015, 9:20am

ops, sure, i'll correct it

jensens · June 25, 2015, 9:31am

@djay direct attributes access works, because dexterity has its own permission validator respecting fields read permission:

github.com

plone/plone.dexterity/blob/master/plone/dexterity/content.py#L155


    assignable = IBehaviorAssignable(inst, None)
    if assignable is not None:
        for behavior_registration in assignable.enumerateBehaviors():
            if behavior_registration.marker:
                dynamically_provided.append(
                    behavior_registration.marker
                )
finally:
    del self.__recursion__


if not dynamically_provided:
    # rare case if no schema nor behaviors with markers are set
    inst._v__providedBy__ = updated + (None, )
    return spec


dynamically_provided.append(spec)
all_spec = Implements(*dynamically_provided)
inst._v__providedBy__ = updated + (all_spec, )


return all_spec

github.com

plone/plone.dexterity/blob/master/plone/dexterity/content.py#L252


        if portal_type:
            fti = queryUtility(ITypeInformation, name=portal_type)
            if fti is not None and not fti.isConstructionAllowed(self):
                raise ValueError(
                    'You can not add the copied content here.'
                )


def _getCopy(self, container):
    # Copy the _v_is_cp and _v_cp_refs flags from the original
    # object (self) to the new copy.
    # This has impact on how children will be handled.
    # When the flags are missing, an Archetypes child object will not have
    # the UID updated in some situations.
    # Copied from Products.Archetypes.Referenceable.Referenceable._getCopy
    is_cp_flag = getattr(self, '_v_is_cp', None)
    cp_refs_flag = getattr(self, '_v_cp_refs', None)
    ob = super(PasteBehaviourMixin, self)._getCopy(container)
    if is_cp_flag:
        setattr(ob, '_v_is_cp', is_cp_flag)
    if cp_refs_flag:
        setattr(ob, '_v_cp_refs', cp_refs_flag)

Write permissions are not covered (so Archetypes did a better job here).

I doubt behavior lookup by adapter factory is possible TTW. We then would need an defined API looking up behaviors.
Once adapter is looked up, permissions checking here is upon the custom adapter and not in the domain of core dexterity.

tkimnguyen · June 25, 2015, 2:24pm

I remember running into this very issue with TTW attribute access. It's confusing to non-core types like me why sometimes it will work and sometimes it won't. @jensens, your explanation is great but it's not something we can tell regular people.

djay · June 25, 2015, 2:57pm

its a shame the design of dexterity didn't take restrictedpython into account. I can't see an easy way out other than lots and lots of documentation explaining how do do things TTW next to how to do them via the filesystem. At the moment most of our documentation assumes filesystem access which is even more confusion.