serialize and deserialize references

[froh]

Hi,

I'm experimenting with Ecore.xsd and various .ecore models, like, for example, Ecore.ecore.

To get a more pythonic API, I'd like to give namespace-like 'things' a __getitem__/__setitem__ (packages, classes, parameter lists of EOperations, and yes, EOperations can be overloaded, so the getitem would return a list.)

Note this is not about lowering, i.e. __getattr__/__setattr__, but about more convenient metaprogramming.

now I wonder how I best inject such derived classes into the parse?

Do I inject classes into the XmlContext.xsi_cache, via XmlContext,reset() and derivation (with a myXYZ.Meta.name = "XYZ")?
or do I dispatch in a ParserConfig.class_factory?

I found no hooks whatsoever in the generator for this, so I want to leave that alone.

PS for the $SUBJECT: I also want to build namespace trees during the parse and substitute references by the referenced object, or a trampoline in the namespace tree.

[tefra]

I am thinking of adding the ability to specify a base class for all the generated models, would that fit your needs?

[rvalyi]

@froh should answer for her use case but as for ourselves we would like such a feature a lot. We were using generateDS previously and it had this feature. Being able to specify which base class to inject in wich generated class would also be a win.

Our use case is electronic invoice generation. There are validations associated to the xsd schema and other "business" validations like ensuring the sum of all line amounts equals the total amount of the invoice. Having such custom subclass would help implenting this kind of features.

[froh]

interesting idea. I wonder if a single shared base class would be sufficient.

hm.

how about an @annotation instead?

then that annotation can work with the generated class at load time, in whichever way is needed.

so generated classes looks roughly like this

from baz import foofoobar

@foofoobar
@dataclass...
class ...:
    class Meta:
         ...

then the pair of import and annotation is given as generator parameters.

traveling, on mobile I hope this is roughly right, I can't look up right now if the foofoobar should come before or after the dataclass annotation to inject another base. possibly it should go in between, like so:

from baz import foofoobar

@dataclass...
@foofoobar
class ...:
    class Meta:
         ...

[tefra]

I added the ability to extend the generated classes with decorators and base classes, have a look and let me know if that works for you!

The feature is on master and will be on the next release

https://xsdata.readthedocs.io/en/latest/examples/extending-models.html

[froh]

I was on parental leave, thus my very delayed response. I very much appreciate this feature it's perfect for my use case. thank you so much :-)

[froh]

I especially appreciate the flexibility to pattern match on the class name and to both decorate and baseclass even selectively 🙇