On 19-Jun-05, at PM 06:16, stéphane ducasse 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.

I'm not sure if I understand you correctly, are you looking for a library for object serialisation to XML? I remember there is at least 1 of those on SM. Or you can just rip the serialization code out from the Squeak XML/RPC client?

-- HweeBoon http://motionobj.com/blog/

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. Finally, I add a master decodeXML: method somewhere in my system that looks at the tag and then calls decodeXML: on the proper class. At first, the master decodeXML: method has a long list of ifTrue:'s in it to select the class to restore, but if the system lasts long enough I'll end up making a Dictionary that maps XML tag names into class objects.

Actually, usually I don't use XML per se if I am just doing Squeak work. I convert to trees of arrays, analagous to s-expressions, and I don't convert small objects such as integers, floats, and points -- classes that are extremely unlikely to change for the duration of time that my external files should last. I then export and import the array trees using SmartRefStream. This is Squeak-specific, but it is a little more convenient and it does not cause problems with cross-version compatibility.

There is a meme going around that you should use an automatic serializer for this kind of thing, but if you do so then in practice you sacrifice cross-version compatibility. That is, if you use an automatic serializer -- be it SIXX, SmartRefStream, or ImageSegment -- then files you create today will probably not be loadable after your software has evolved for several months. The problem is that you will tend to refactor your code as it evolves, creating new classes and eradicating old ones, and thus the serialized files will specify classes that no longer exist.

There is substantial room for improvement in this pattern, but it is somewhere to start. I yearn for the day that serialization is treated more seriously, the day when software folks lose their fanatacism with low-level file formats (XML) and silver bullets (automatic serialization).

-Lex

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