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