XML Facade instead of value objects?
I have a project I'm working on where it'd be great if older versions of the software preserved information in the XML file format that it didn't understand. For example, imagine if Version 1 (V1) of the software had this for a file format:
<data>
<value>1</value>
</data>
Now imagine if V2 of the file added an attribute
<data>
<value type="number">1</value>
</data>
It'd be great if you opened that second file with the V1 software and then saved it again, it would preserve the stuff it didn't understand. Unfortunately that's not how I usually write my value objects. Usually I do something like:
As you can see, anything in the file that it doesn't understand is lost. But what if we followed a facade pattern for our data objects and did something more like this:
They both have the exact same API, but the second one will preserve XML attributes (or even nodes) that it doesn't understand.
What about AMF based projects, especially when passing rich objects with a Red5 server? I know there's a pretty seamless mechanism in place if properties aren't known, but how do you get those unknown properties back to the server?
What other solutions or best-practices do other people follow for solving this issue?
<data>
<value>1</value>
</data>
Now imagine if V2 of the file added an attribute
<data>
<value type="number">1</value>
</data>
It'd be great if you opened that second file with the V1 software and then saved it again, it would preserve the stuff it didn't understand. Unfortunately that's not how I usually write my value objects. Usually I do something like:
public class ValueObject
{
public var value:Number;
public static function fromXML( xml:XML ) : ValueObject
{
var v:ValueObject = new ValueObject();
v.value = xml.value;
}
public function toXML( ) : XML
{
var xml:XML = <data>;
xml.value = value;
return xml;
}
}
As you can see, anything in the file that it doesn't understand is lost. But what if we followed a facade pattern for our data objects and did something more like this:
public class ValueObject
{
protected var source:XML;
public static function fromXML( xml:XML ) : ValueObject
{
v.source = xml;
}
public function toXML() : XML
{
return source;
}
public function get value() : Number {return source.value;}
public function set value(val:Number) : void {source.value = val;}
}
They both have the exact same API, but the second one will preserve XML attributes (or even nodes) that it doesn't understand.
What about AMF based projects, especially when passing rich objects with a Red5 server? I know there's a pretty seamless mechanism in place if properties aren't known, but how do you get those unknown properties back to the server?
What other solutions or best-practices do other people follow for solving this issue?
Labels: Actionscript, actionscript 3, red5, xml
3 Comments:
The facade pattern certainly works, but I'm thinking it's a bit overkill and, perhaps, indicative of a need to re-evaluate the algorithm altogether.
The facade pattern is an access pattern. You don't have problems with access, you have problems maintaining unused data (or data the particular version doesn't know about).
Rather than recreating the XML object from scratch, why not simply modify the original? Keep a copy of it around, or request it again, modify it, then spit out the modified copy.
Hope that helps.
By
eric, At
11/19/2007 10:42 AM
Thanks for the comment Eric certainly some good stuff to think about. I'll have to try it out that way and see which way I like better.
Maybe the big leap for me was recreating the XML object vs. not recreating it. I had been imagining ugly schemes of somehow parsing and remembering extra data and then recreating it on data-out time which is obviously not the way to do it.
Eventually, my long term goal is to automatically generate value objects based on some definition (like JAXB does in the java world). I wonder which method would make fore cleaner gen-code.
By
Marc, At
11/19/2007 10:58 AM
tapgyn@gmail.com
mail me I want to talk to you and I can't find your mail address.
By
Oficina7, At
12/09/2007 7:40 PM
Post a Comment
Subscribe to Post Comments [Atom]
<< Home