Blueprint: Api Refactoring about alfodoo HOT 5 CLOSED

a lot of drawbacks

N'exagérons rien 😉

s/Folder/CmisFolder/ ?

openerp.addons.cmis is the one in connector-cims?

Questions regarding field properties:

• backend_domain could be left for later, create_method is sufficient for now?
• cmis_path may be not a field property at the beginning: this can be computed in the create method?
• What's the purpose of cmis_object_type ?

from alfodoo.

s/Folder/CmisFolder/ ?

s/openerp.addons.cmis.fields.Folder/openerp.addons.cmis.fields.CmisFolder why not. CmisFolder was my first idea but the cmis prefix seems to be a redundant information since the field is defined under the openerp.addons.cmis namespace . But it's true that declaring a property xxx = fields.CmisFolder( removes any ambiguity when reading the code. -> 👍

openerp.addons.cmis is the one of connector-cmis?

Yes it is. Nevertheless IMO that's the right ns to provide the bases to integrate odoo with a cmis container. Here is the list of the addon names I imagine to provide the current functionalities.

• cmis (bakend, fields, but no more dependency on connector)
• cmis_alf (bakend extension for alfresco)
• cmis_web (replaces web_cmis_viewer and provides all the cmis widgets)
• cmis_web_alf (wdiget extensions for alfresco)
• cmis_connector (could provide the specific functionalities that depend of the connector addon)
• ....

• backend_domain could be left for later, create_method is sufficient for now?

Why not but it's a safe way to remove the hard coded domain currently used by the widget. https://github.com/acsone/alfodoo/blob/9.0/web_cmis_viewer/static/src/js/web_cmis_viewer_widget.js#L349

*cmis_path may be not a field property at the beginning: this can be computed in the create method?

IMO the create method is to use in complex cases (when you need to provide specific cmis properties) . I imagine that the field will provide a default method that will create the folder as sub-folder of the cmis_path with a cm:name provided by the cmis_name_get method. The question with this default method is how can it be called by the web since it'ts not defined on the model itself. ( A specific controller?) In a first time we can declare the create_method as required. The advantage is that the method name will be available into the field description provided to the widget and callable on the model.

• What's the purpose of cmis_object_type ?

A step too far... the purpose is to provide a parameter to specify a custom cmis type to create in place of cmis:folder

from alfodoo.

@sbidoul a basic implementation can be found here https://github.com/acsone/connector-cmis/blob/9.0-cmis-field.
The central piece is https://github.com/acsone/connector-cmis/blob/9.0-cmis-field/cmis/fields.py and you can see how it works in https://github.com/acsone/connector-cmis/blob/9.0-cmis-field/cmis/tests/models.py and https://github.com/acsone/connector-cmis/blob/9.0-cmis-field/cmis/tests/test_fields.py
At this stage the backend name is not stored in the field value. Indeed, IMO, we can avoid to store the backend_name into the field value since it"s always available on the field definition.

from alfodoo.

At this stage the backend name is not stored in the field value. Indeed, IMO, we can avoid to store the backend_name into the field value since it"s always available on the field definition.

Yes, it's simpler.

from alfodoo.

merged 5162a29

from alfodoo.