[Erp5-dev] Attribute Lookup and ERP5Type.Base

[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.



Le Mardi 4 Avril 2006 14:06, Patrick Gerken a écrit :
> 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-Solanes, Nexedi CEO - Tel. +33(0)6 62 05 76 14
Nexedi: Consulting and Development of Libre / Open Source Software
http://www.nexedi.com
ERP5: Libre/ Open Source ERP Software for small and medium companies
http://www.erp5.org
Rentalinux: Desktop Linux Server
http://www.rentalinux.com