[REF] spec_driven_model: s/generateds/xsdata/ refs

Author: rvalyi

spec_driven_model/models/spec_export.py

@@ -51,7 +51,7 @@ def _export_fields(self, xsd_fields, class_obj, export_dict):
         This method implements a dynamic dispatch checking if there is any
         method called _export_fields_CLASS_NAME to update the xsd_fields
         and export_dict variables, this way we allow controlling the
-        flow of fields to export or injecting specific values ​​in the
+        flow of fields to export or injecting specific values in the
         field export.
         """
         self.ensure_one()
@@ -118,10 +118,6 @@ def _export_field(self, xsd_field, class_obj, field_spec, export_value=None):
                 if field.comodel_name not in self._get_spec_classes():
                     return False
             if hasattr(field, "xsd_choice_required"):
-                # NOTE generateds-odoo would abusively have xsd_required=True
-                # already in the spec file in this case.
-                # In xsdata-odoo we introduced xsd_choice_required.
-                # Here we make the legacy code compatible with xsdata-odoo:
                 xsd_required = True
             return self._export_many2one(xsd_field, xsd_required, class_obj)
         elif self._fields[xsd_field].type == "one2many":
@@ -135,7 +131,7 @@ def _export_field(self, xsd_field, class_obj, field_spec, export_value=None):
             and self[xsd_field] is not False
         ):
             if hasattr(field, "xsd_choice_required"):
-                xsd_required = True  # NOTE compat, see previous NOTE
+                xsd_required = True
             return self._export_float_monetary(
                 xsd_field, xsd_type, class_obj, xsd_required, export_value
             )
@@ -147,19 +143,19 @@ def _export_field(self, xsd_field, class_obj, field_spec, export_value=None):
     def _export_many2one(self, field_name, xsd_required, class_obj=None):
         self.ensure_one()
         if field_name in self._get_stacking_points().keys():
-            return self._build_generateds(
+            return self._build_binding(
                 class_name=self._get_stacking_points()[field_name].comodel_name
             )
         else:
-            return (self[field_name] or self)._build_generateds(
-                class_obj._fields[field_name].comodel_name
+            return (self[field_name] or self)._build_binding(
+                class_name=class_obj._fields[field_name].comodel_name
             )
 
     def _export_one2many(self, field_name, class_obj=None):
         self.ensure_one()
         relational_data = []
         for relational_field in self[field_name]:
-            field_data = relational_field._build_generateds(
+            field_data = relational_field._build_binding(
                 class_name=class_obj._fields[field_name].comodel_name
             )
             relational_data.append(field_data)
@@ -192,8 +188,7 @@ def _export_datetime(self, field_name):
             ).isoformat("T")
         )
 
-    # TODO rename _build_binding
-    def _build_generateds(self, class_name=False, spec_schema=None, spec_version=None):
+    def _build_binding(self, spec_schema=None, spec_version=None, class_name=None):
         """
         Iterate over an Odoo record and its m2o and o2m sub-records
         using a pre-order tree traversal and map the Odoo record values
@@ -206,7 +201,7 @@ def _build_generateds(self, class_name=False, spec_schema=None, spec_version=Non
         self.ensure_one()
         if spec_schema and spec_version:
             self = self.with_context(
-                self.env, spec_schema=spec_schema, spec_version=spec_version
+                spec_schema=spec_schema, spec_version=spec_version
             )
         spec_prefix = self._spec_prefix(self._context)
         if not class_name:
@@ -229,27 +224,9 @@ def _build_generateds(self, class_name=False, spec_schema=None, spec_version=Non
         kwargs = {}
         binding_class = self._get_binding_class(class_obj)
         self._export_fields(xsd_fields, class_obj, export_dict=kwargs)
-        if kwargs:
-            sliced_kwargs = {
-                key: kwargs.get(key)
-                for key in binding_class.__dataclass_fields__.keys()
-                if kwargs.get(key)
-            }
-            binding_instance = binding_class(**sliced_kwargs)
-            return binding_instance
-
-    def export_xml(self):
-        self.ensure_one()
-        result = []
-        if hasattr(self, f"_{self._spec_prefix(self._context)}_spec_settings"):
-            binding_instance = self._build_generateds()
-            result.append(binding_instance)
-        return result
-
-    def export_ds(
-        self, spec_schema, spec_version
-    ):  # TODO change name -> export_binding!
-        self.ensure_one()
-        return self.with_context(
-            spec_schema=spec_schema, spec_version=spec_version
-        ).export_xml()
+        sliced_kwargs = {
+            key: kwargs.get(key)
+            for key in binding_class.__dataclass_fields__.keys()
+            if kwargs.get(key)
+        }
+        return binding_class(**sliced_kwargs)

spec_driven_model/models/spec_import.py

@@ -21,7 +21,7 @@ class SpecMixinImport(models.AbstractModel):
     _name = "spec.mixin_import"
     _description = """
     A recursive Odoo object builder that works along with the
-    GenerateDS object builder from the parsed XML.
+    xsdata object builder from the parsed XML.
     Here we take into account the concrete Odoo objects where the schema
     mixins where injected and possible matcher or builder overrides.
     """
@@ -31,7 +31,7 @@ def build_from_binding(self, spec_schema, spec_version, node, dry_run=False):
         """
         Build an instance of an Odoo Model from a pre-populated
         Python binding object. Binding object such as the ones generated using
-        generateDS can indeed be automatically populated from an XML file.
+        xsdata can indeed be automatically populated from an XML file.
         This build method bridges the gap to build the Odoo object.
 
         It uses a pre-order tree traversal of the Python bindings and for each

spec_driven_model/models/spec_view.py

@@ -133,7 +133,7 @@ def _build_spec_fragment(self, container=None):
     # TODO required only if visible
     @api.model
     def build_arch(self, lib_node, view_node, fields, depth=0):
-        """Creates a view arch from an generateds lib model arch"""
+        """Creates a view arch from an xsdata lib model arch"""
         # _logger.info("BUILD ARCH", lib_node)
         choices = set()
         wrapper_group = None

spec_driven_model/readme/DESCRIPTION.rst

@@ -1,7 +1,7 @@
 Intro
 ~~~~~
 
-This module is a databinding framework for Odoo and XML data: it allows to go from XML to Odoo objects back and forth. This module started with the `GenerateDS <https://www.davekuhlman.org/generateDS.html>`_  pure Python databinding framework and is now being migrated to xsdata. So a good starting point is to read `the xsdata documentation here <https://xsdata.readthedocs.io/>`_
+This module is a databinding framework for Odoo and XML data: it allows to go from XML to Odoo objects back and forth. While having no hard dependency with it, it has been designed to be used with xsdata. So a good starting point is to read `the xsdata documentation here <https://xsdata.readthedocs.io/>`_
 
 But what if instead of only generating Python structures from XML files you could actually generate full blown Odoo objects or serialize Odoo objects back to XML? This is what this module is for!
 
@@ -26,7 +26,7 @@ Now that you have generated these Odoo abstract bindings you should tell Odoo ho
 
 Notice you should inherit from `spec_models.SpecModel` and not the usual `models.Model`.
 
-**Field mapping**: You can then define two ways mapping between fields by overriding fields from Odoo or from the binding and using `_compute=` , `_inverse=` or simply `related=`.
+**Field mapping**: You can then define two ways mapping between fields by overriding fields from Odoo or from the binding using `_compute=` , `_inverse=` or simply `related=`.
 
 **Relational fields**: simple fields are easily mapped this way. However what about relational fields? In your XSD schema, your electronic invoice is related to the `partner.binding.mixin` not to an Odoo `res.partner`. Don't worry, when `SpecModel` classes are instanciated for all relational fields, we look if their comodel have been injected into some existing Odoo model and if so we remap them to the proper Odoo model.
 
@@ -36,7 +36,7 @@ Notice you should inherit from `spec_models.SpecModel` and not the usual `models
 StackedModel
 ~~~~~~~~~~~~
 
-Sadly real life XML is a bit more complex than that. Often XML structures are deeply nested just because it makes it easier for XSD schemas to validate them! for instance an electronic invoice line can be a nested structure with lots of tax details and product details. In a relational model like Odoo however you often want flatter data structures. This is where `StackedModel` comes to the rescue! It inherits from `SpecModel` and when you inherit from `StackedModel` you can inherit from all the generated mixins corresponding to the nested XML tags below some tag (here `invoice.line.binding.mixin`). All the fields corresponding to these XML tag attributes will be collected in your model and the XML parsing and serialization will happen as expected::
+Sadly real life XML is a bit more complex than that. Often XML structures are deeply nested just because it makes it easier for XSD schemas to validate them! for instance an electronic invoice line can be a nested structure with lots of tax details and product details. In a relational model like Odoo however you often want flatter data structures. This is where `StackedModel` comes to the rescue! It inherits from `SpecModel` and when you inherit from `StackedModel` you can inherit from all the generated mixins corresponding to the nested XML tags below some tag (here `invoice.line.binding.mixin`). All the fields corresponding to these XML tag attributes will be collected in your model and the XML parsing and serialization will happen as expected. Here is an example inspired from the Brazilian Electronic Invoice where the schema is called `nfe` and where we use the 2 digits `40` for its short version::
 
 
   from odoo.addons.spec_driven_model.models import spec_models
@@ -45,14 +45,21 @@ Sadly real life XML is a bit more complex than that. Often XML structures are de
   class InvoiceLine(spec_models.StackedModel):
       _inherit = [
           'account.move.line',
-          'invoice.line.binding.mixin',
+          'nfe.40.det',
       ]
-      _stacked = 'invoice.line.binding.mixin'
+      _nfe40_spec_settings = {
+          "module": "odoo.addons.l10n_br_nfe_spec.models.v4_0.leiaute_nfe_v4_00",
+          "stacking_mixin": "nfe.40.det",
+          "stacking_points": {},
+          # all m2o below this level will be stacked even if not required:
+          "stacking_force_paths": ("det.imposto.",),
+          "stacking_skip_paths": ("nfe40_det_infNFe_id",),
+      }
 
-All many2one fields that are required in the XSD (xsd_required=True) will get their model stacked automatically and recursively. You can force non required many2one fields to be stacked using the `_force_stack_paths` attribute. On the contrary, you can avoid some required many2one fields to be stacked using the `stack_skip` attribute.
+All many2one fields that are required in the XSD (xsd_required=True) will get their model stacked automatically and recursively. You can force non required many2one fields to be stacked using the `stacking_force_paths` attribute. On the contrary, you can avoid some required many2one fields to be stacked using the `stacking_skip_paths` attribute.
 
 
-Hooks
-~~~~~
+Initialization hook
+~~~~~~~~~~~~~~~~~~~
 
-Because XSD schemas can define lot's of different models, spec_driven_model comes with handy hooks that will automatically make all XSD mixins turn into concrete Odoo model (eg with a table) if you didn't inject them into existing Odoo models.
+Because XSD schemas can define lot's of different models, spec_driven_model comes with a handy _register_hook that will automatically make all XSD mixins turn into concrete Odoo model (eg with a table) if you didn't inject them into existing Odoo models.

spec_driven_model/tests/test_spec_model.py

@@ -124,7 +124,7 @@ def test_create_export_import(self):
 
         # 2nd we serialize it into a binding object:
         # (that could be further XML serialized)
-        po_binding = po._build_generateds(spec_schema="poxsd", spec_version="10")
+        po_binding = po._build_binding(spec_schema="poxsd", spec_version="10")
         self.assertEqual(
             [s.__name__ for s in type(po_binding).mro()],
             ["PurchaseOrderType", "object"],