Question: What do classes in a custom component need to do to assure they are digested properly by the serializer in Ignition?
The reason I ask is that I know that one of the large sets of classes I might use are known to not implement java.io.Serializable and are thus not inherently serializable. Is this the rule? Or is Ignition doing other things (e.g. XMLSerializer) that allows these objects to be serialized when they would otherwise not be!?
The vision module doesn’t use java.io style serialization, so that doesn’t matter.
We use a serializer that was inspired by the java.beans.XMLEncoder, but it’s custom.
The normal use of it is pretty simple: your classes need:
Only fields with getters and setters will be serialized.
Carl,
Cool. That makes a lot of sense. So basically you just capture the class that is placed (in the case of a Component) and whatever properties are exposed by bean-style getters/setters. Then when you reconstitute things (deserialize) you just instantiate on the empty constructor and run through all the setters with the captured values? Is this correct comprehension?
So really if this is the case, it completely nullifies the concern of having to handle serialization within my classes – just so far as that I can initialize appropriately on an empty constructor and that everything that needs to be reinstated comes off the exposed properties?
Thanks!
Yes, that's exactly right. The only "gotcha" is that you need to realize when authoring your component that your setters will be called during deserialization, which is before your component is "started up". Usually not a big deal, but something to keep in mind as you're coding. To run code after you've been started up, override the onStartup() method.
That’s good (set at deserialize and prior to startup) since it follows the logic that I initialize into a preset universe - that my datasets and other parameters are ‘lit up’ before I start running. Thanks for the clarification!