[Erp5-dev] Attribute Lookup and ERP5Type.Base

[Patrick Gerken]

Hello,

today I was hunting a really strange behaviour, in our ERP5 system.
I was trying to retrieve a Category via searchFolder(), and got back a
None object. also a direct access via category.category_to_search_for
returned None. category.__getattr__('category_to_search_for') returned
the correct category.
Diving deep into attribute resolving, it appeared, that somehow my
category_to_search_for has sneaked into the __dict__ attribute of the
Base Class ERP5Type.Base. Therefor the lookup in all base classes of
the class of the category instance finds the item, and __getattr__
gets never called.
Carefully looking into that __dict__, I saw many, maybe twohundred
entries in there. That seems to be the source of the annoying
twohundred results when I try a dir() on an erp5 object.
I deleted the __dict__ entry by hand and everything was fine, but I am
trying to understand, how it got there, and more importantly, what is
going on in ERP5Type.Base. Is this some form of getting faster lookups
for dynamically generated accessors?

Maybe someone here can provide some insight

[Jean-Paul Smets]

A None value is set on the Base class for every property defined in a
propertysheet. The purpose of this is to prevent acquisition on properties.

ERP5 is designed with the following in mind:
- we want acquisition for accessors and methods
- we do not want acquisition for properties defines through property sheets

The current implementation does the job. A better implementation (more
explicit) would consist in creating a new class of Acquisition. (Implicit
with explicit exceptions) or to add a prefix to all stored properties (this
is already possible by the way).

More generally, if a folderish object has a property "X" and we create a
subobject with id "X", then there is no way to access X through traversal.

Try for example to create a folder in a folder in Zope and try to give that
folder id "title".

So, the correct behaviour in ERP5 would be to prevent from creating an
object which id is the is of a property. setId should raise an exception
and lead to a message such as:

The id "X" is invalid - it is already in use.

This is fine as long as we do not add more properties during the lifecycle
of an ERP5 application. If properties are added after 1 year of production
and one such property conflicts with the id of an object, then this object
must be renamed...

This is why we prefer to use numbers for ids rather than words. The notable
exceptions are:
1- root objects (ex. modules)
2- subobjects which are defined within propertysheets
3- category ids
4- domain ids

The only case which I see problematic is 3- and 4- for which the rule should
be to never use an id which is also the id of a property.

I think this mail should become a technical note. I already added a small
par. to
http://wiki.erp5.org/GuidelinesForCodingCrimes

but a technical note would be good.

JPS.

Post by Patrick Gerken
Hello,
today I was hunting a really strange behaviour, in our ERP5 system.
I was trying to retrieve a Category via searchFolder(), and got back a
None object. also a direct access via category.category_to_search_for
returned None. category.__getattr__('category_to_search_for') returned
the correct category.
Diving deep into attribute resolving, it appeared, that somehow my
category_to_search_for has sneaked into the __dict__ attribute of the
Base Class ERP5Type.Base. Therefor the lookup in all base classes of
the class of the category instance finds the item, and __getattr__
gets never called.
Carefully looking into that __dict__, I saw many, maybe twohundred
entries in there. That seems to be the source of the annoying
twohundred results when I try a dir() on an erp5 object.
I deleted the __dict__ entry by hand and everything was fine, but I am
trying to understand, how it got there, and more importantly, what is
going on in ERP5Type.Base. Is this some form of getting faster lookups
for dynamically generated accessors?
Maybe someone here can provide some insight