This page explains the current status (october 2009) of the way of identifying category of classes. Note that for now there is not real use of categories, but the intention is
really similar to categories.
Table of Contents
Current Status¶
- We have many is[Category] properties on class. For example isIndexable, isMovement, isDelivery. For now, this property is almost everywhere a constant boolean.
- We have some is[Category] method on class. Having a constant boolean was not sufficient is some cases, like isMovement. So the current state of isMovement is really inconsistent,
sometimes it is boolean, sometimes it is a method returning a boolean.
- We have no way to know if a class implement a particular interface.
- We have similar thing with list of portal types. For example we have a group of portal types called "Movement", and we have the method getPortalMovementTypeList. This is not
always the same thing, but may be there is things to merge here.
Analysis¶
- Probably initially having a constant boolean for is[Category] was quite equivalent with the idea to implement some particular interface. But now, because is[Category] is not
always constant, it seems that two different things are needed. Indeed, the notion of "do we implement Movement interface" is something different than "are we movement right
now ?". So it would ge great to have first something like "implementsIMovement()", or "isIMovement", or "providesIMovement", then having a second method isMovement() that will do
the same thing as it is now.
- More analysis will be required in order to check the list of duplicates with getPortal[XXX]TypeList
Suggestions¶
- Add some code in Utils.py in order to parse all interfaces, and for every class generate a Constant Accessor "implementsI[interface_name]" (or "isI[interface_name]").
- For all is[Category] boolean that already exist (like isIndexable = 1), generate a method Constant Accessor. This can be done in the same way as previous point : at the time
where we generate methods for a portal type. For now there is probably no other way than having an hardcoded list of theses properties in Utils.py.
- Keep compatibility with existing code by using a Constant Getter accessor that can behave like a property (with methods nonzero and others, see ERP5Type/Accessor/Constant.py).
So it will be possible to keep code like "if document.isIndexable: ...".
Questions¶
- How should we define future is[Category] in the future ? Should we continue to define a boolean on the class and then modify Utils.py every time ? It can sounds strange to
define a boolean if at the end we wish to use methods (of course right now having compatibility is good).
- Is there any interest to generate all Constant Accessor in Utils.py (for isIndexable, isTempDocument...) instead of directly setting on classes something like :
isIndexable = ConstantGetter(True) . Generating them for every portal type with _aq_dynamic is more memory/time consuming, so
it's not good if we don't have benefit.
- Is it nice to use the Contant Accessor for "implementsI[interface_name]" ? Theses method does not exist yet, it could be not so nice to let the possibility to use 2 different
syntax. Some will use code like if they use a property, some other will use it like a method. This makes things complicated if we want to override and will make the code less
understandable.
Answers¶
- For the different names isIMovement, implementsIMovement... implementsIMovement is better
- For implementsIMovement, we should only use methods, not ConstantGetter.
- When real methods should be used and are usefull, like isMovement(), isIndexable(), then proper API should be defined.
- all getPortal[Category]TypeList should be based on categories. The base category for this should be "portal_type_group" (may be a
better name is needed), we will find for example portal_type_group/delivery, portal_type_group/rule, etc.
- most is[Category] should be replaced by something else. Indeed, many things like isDocument are really duplicates of getPortalDocumentTypeList. So it is meaningless to keep
both. We should instead extend API in order to have method that will check automatically if the current type is inside getPortal[Category]
TypeList(). We can use ConstantGetter for compatibility reasons for now.We should use better name, like isPortal[Category]
Type
Remarks¶
- isMovement() will be always a method, we will remove isMovement property. Also, implementsIMovement is now available.
- isDelivery property is useless, please use object.isDeliveryType() or implementsIDelivery() (this api does not exists yet)
- isCapacity is useless, please use implementsICapacity (this api does not exists yet)
- isCategory is useless, please us implementsICategory (this api does not exists yet)
- isBaseCategory is use in only one place
- isInventoryMovement is useless, use object.isInventoryMovementType() instead
- isInventory could be useless and it could be enough to use implementsIInventory() when the api will be defined
- isIndexable() is usefull and will be used as a method. For backward compatibility, we will make it working like an integer for some time. We really need a method, the value
can be true or false depending on calculation.
- isPredicate is useless, use object.implementsIPredicate() instead
- isTemplate is used only in ERP5Type/Base.py someone needs to take decision
- isDocument is useless, please use object.isDocumentType() instead. It would also be possible to use implementsIDocument()
- isTemplateDocument is usefull and should only be used as a method. For backward compatibility, we will make it working like an integer for some time.
Related Articles¶