Analysing sandwich serialization
If we take our :ref:`example<demonstration-ref>` with sandwiches and breads, here is the representation of what actually happens when we use sandwich_srz.spit. Serializers are represented as triangles, input on the left, output on the right.
As this schema illustrates, SpitEat is based on two principles :
All (de)serializations should be treated as a recursive operations. Each serializer:
- Decomposes (de)serialization in sub-operations
- Delegates those sub-operations to other serializers (this implies to be able to find an appropriate serializer for any Python instance, see 2. ;-)
- Combines the sub-operations' results
There is a suitable serializer for every single python class. So it is always possible to delegate. Indeed, the identity is the simplest operation, and that's why :class:`simple.IdentitySrz` is used by default for instances of :class:`object`.
Flexibility and code re-use
This architecture allows both a lot of flexibility, and a lot of code re-use.
because each serializer does only a minimum amount of work, and delegates the rest. This also enables to implement generic serializers, which implement some common (de)serialization patterns (for example, :class:`simple.ContainerSrz`, :class:`objectsrz.ObjectSrz`, ...).
because being able to easily plug-in your own serializer makes it very easy to customize the output, e.g. chosing which serializer an :class:`objectsrz.ObjectSrz` uses for a given attribute, or chosing which serializer a :class:`base.Srz` uses for a given class, are several examples of mecanisms enabling plugging-in your own serializer.
So what have you got ?
To summarize this abstract nonsense ... SpitEat provides several base classes for serializers, most of thoses are usable as-is and provide many settings so you don't even need to override them. But ! If you want to start a serializer from scratch, you can still subclass :class:`base.Srz` which provides building blocks helping you to delegate operations, find a serializer to delegate to, etc ...