Lex Spoon wrote:
I have an object that I want to serialize in XML now this object contains a date object of course I can save it explicitly as a string and do a readFrom.... But I wanted to know if there is a more advance serialization process.
My usual pattern for this is to put xmlForExport methods on every class I want to be able to save, and then have decodeXML: methods on the class side of these same classes.
I was doing something similar to this, but my application requires that I be able to export the same objects to multiple different XML formats, many of which have identically named elements with different internal structure. The structure of the nodes in any given export format does not correspond particularly well to that of my native objects. I need to be able to add new export formats quickly and easily.
To solve my problem, I have partially implemented a library whose main class is called XSDClassFactory. It takes an XML Schema Definition. If you don't already have one, you can construct an XSD from one or several XML files using publically available tools. XSDClassFactory reads the XSD and creates classes with the corresponding structure in Squeak. The classes know how to read, write & validate XML which adheres to the corresponding XSDs, and you can access the data using instance variable accessors instead of the usual YAXO methods, which means code that uses the generated classes is a lot clearer. I am trying to get this library finished up & publically released in the next month or two; I've been lazy & haven't implemented all the standard/built-in XML types yet. I think a couple of pre-alpha testers would be helpful at this point; contact me off-list if you'd like to be one.
Here is part of my XSDType class comment about how to do mappings with XSDClassFactory classes. Alpha, not fully tested, may change, blah blah blah, but it is a pattern to use as a straw man.
---- * You will need to manually define mapping methods to make this work for new subclasses. I wrote XSDClassFactory to make it easy for me to teach an application new XML formats, so all the mappings in my system are between my native types (SourceClass) and XSDType (TargetClass) subclasses, which I treat as a static output (and occasionally input) format. Here is what I am doing:
- Use the naming convention TargetClass>>fromSourceClass: for all conversion methods, in both directions. This naming convention is preferred to SourceClass>>asTargetClass because the protocol of the SourceClass and the TargetClass are typically different. - At the top of the SourceClass hierarchy, define a method called SourceClass>>convertToFormat: which takes a TargetClass, finds the most specific fromSourceClass: message that particular TargetClass will understand, and passes back its answer. - In SourceClass, define a registry containing interesting TargetClasses. - Construct the save as.. menu from the registry. - To output to a new XML format, run an XSD through XSDClassFactory, add the resulting TargetClasses to the appropriate SourceClass registries, and write some fromSourceClass: methods in each TargetClass. ----
Note that the above does not solve the problem Lex was solving with the case statement & future dictionary, wherein the system can automatically instantiate the correct classes based on the XML received. Solving that problem using only XML element names will inherently suffer from XML namespace collision issues. I think there are sometimes cues in the attributes (maybe explicit namespace declaration?), but I haven't looked into it.
Brenda