Anatomy of a Serializer (v1.x)

Let’s start with an example. Suppose we know that our data model contains a “simple class” called B:

In order to make use of this class with the Zeno framework, we need to create an NFTypeSerializer to mirror this class:

Let’s take a closer look at this serializer. A serializer for a specific class contains five components.

• A name for this type. We define this by passing a single argument to super() in the constructor. This name can be anything, and will be used to reference this type by other serializers. Because this name is used to identify the serializer, it must be unique for each serializer.
• A definition of how to deconstruct (or “serialize”) this class into its individual components. The classes comprising our data model should ideally be simple containers, and contain no business logic. This method should therefore be very formulaic and list off each of the fields for the Object, following the pattern shown.
• A definition of how to reconstruct (or “deserialize”) an object of this class based on its component pieces. Again, because we have no business logic in our object model classes, this should ideally just gather the values and pass them to the constructor for the class.
• A FastBlobSchema. The examples above show the syntactic sugar required for this; it is again a listing of the fields in the Object.
• Finally, an identification of the serializers for any types which are referenced by this class.

This object contains only an integer and a String, both of which Zeno knows how to deal with natively. What if our object contained fields that Zeno doesn’t know how to deal with natively? Continue on to the next page, “Hierarchical Serializers (v1.x)”, to find out how to deal with this.