2012/10/15 Johan Engelen <jbc.engelen@...2592...>:
I don't like adding the compatibility code to the classes themselves. Also, note that in this case the compatibility-fix is easy: simply change some values. But other compatibility patch-ups may involve more than one new objects or in another place in the SVG. For example, the old-style grid was not an SVG leaf and the patch-up required creating a new leaf.
What about adding a specific compatibility section in our file loading code? So after the XML is loaded, but before all objects are created. So the patch-ups involve modifying the XML. Then when all is well, the object tree is created. This way, all patch-ups are grouped together and don't clutter our codebase in different places.
This approach is completely unmaintainable. You end up implementing a large portion of your build and write functions by hand in a place that is very far from the actual definition of those functions. For example, adding flowtext fallbacks would be a nightmare.
There's a slightly different approach than the one I wrote about initially, but I realized it is far better. Here's what the new object's build function should do: 1. Check the XML element name 2. If it's an old guide, read SPObject values from old XML and fix them up after reading 3. Change the XML element's name to the new one and unset all attributes 4. Call the write function (the same one that's used when updating the XML when an undo event is committed)
This way we do not need to write back the old values to XML as text just to read them again, and we avoid duplicating the code that writes XML.
The better pattern for backward compatibility is to put the transformation to the new XML in the SPObject for old guides, but with our current approach to constructing the SP tree, I don't see any obvious way to do this.
Regards, Krzysztof