We often run into a scenario at work where we have to create an object from xml. More specifically we are parsing xml files with exercise (or assessment item) data to a concrete exercise type like a MultipleChoice, FillGaps, HotSpot, etc. The thing is that we are supporting several xml dialects for the same type of exercise and we end up with a lot of parsers. On top of that we also need to be able to decide on a per project basis what xml dialects are supported (a customer may only be allowed to use dialext X for exercise Y). In the next lines I will try to explain the way we manage and configure the objects that are involved in this process.
The basic idea is that we create a factory, let's call it ExerciseFactory, and define a createFromXML() method on it that takes an xml object as its input and "creates" a concrete exercise as its output. The factory is basically an xml parser. It works as follows:
Actionscript:
-
var exerciseFactory:ExerciseFactory = new ExerciseFactory();
-
var exercise:Exercise = exerciseFactory.createFromXML(xml);
Exercise is the base class for all exercise types like MultipleChoice, FillGaps, etc. The given xml object will be in a format that corresponds to such a concrete type. The factory however needs to know what the given xml is and what concrete exercise type it should return. The easiest way to handle these different xml dialects is with a switch on some property of the xml data. This results in code similar to this (in the ExerciseFactory class):
Actionscript:
-
public function createFromXML(xml:XML):Exercise {
-
var result:Exercise;
-
switch (xml.someProperty) {
-
case multiplechoice-dialect-a:
-
// parse type MultipleChoice with dialect a
-
break;
-
case multiplechoice-dialect-b:
-
// parse type MultipleChoice with dialect b
-
break;
-
case multiplechoice-dialect-c:
-
// parse type MultipleChoice with dialect c
-
break;
-
case fillgaps-dialect-a:
-
// parse type FillGaps with dialect a
-
break;
-
case fillgaps-dialect-b:
-
// parse type FillGaps with dialect b
-
break;
-
default:
-
throw new Error("Cannot create exercise for the given xml object.");
-
}
-
return result;
-
}
Although this works, it is certainly bad design since it is code that is hard to maintain and manage. If we need to add or remove some parsers, we have to modify this code which is buried deep inside some package hierarchy. We can't change this behavior at runtime since the parsers are hardcoded into the switch/case.
We could solve this with a mapping configured inside the ExerciseFactory. As its key, it contains the value of the property in the xml data we did the switch on. As its value it contains the class or an instance of the parser. This results in something like the following:
Actionscript:
-
public function ExerciseFactory() {
-
this.map = {};
-
this.map[multiplechoice-dialect-a] = new MultipleChoiceDialectAParser();
-
this.map[multiplechoice-dialect-b] = new MultipleChoiceDialectBParser();
-
this.map[fillgaps-dialect-a] = new FillGapsDialectAParser();
-
}
-
-
public function createFromXML(xml:XML):Exercise {
-
var parser:ExerciseParser = this.map[xml.someProperty];
-
return parser.parse(xml);
-
}
Ok this seems better, but we can't configure the parsers externally since they are coded in the contructor. Let's externalize this by passing in the map to the constructor and additionally create a method for adding a parser.
Actionscript:
-
public function ExerciseFactory(map:Object) {
-
this.map = map;
-
}
-
-
public function addParser(key:String, parser:ExerciseParser):void {
-
this.map[key] = parser;
-
}
-
-
public function createFromXML(xml:XML):Exercise {
-
var parser:ExerciseParser = this.map[xml.someProperty];
-
return parser.parse(xml);
-
}
This is a neat implementation. We're setting a behavior or strategy for the parser in the factory at runtime, based on some configuration. But it has a drawback: the name of the property (xml.someProperty) in the xml data we use as a key in our map always needs to be the same for the different xml dialects. Unfortunately, we can't really control this because a new dialect might be used one day that does not contain the property.
To solve this, let's add another method to our parsers: canCreate(xml:XML):Boolean. As a parameter, it takes the xml data and then checks if it can parse the data by looking into the xml structure. Finally, it returns a boolean indicating whether or not the xml can be parsed. This way, the parser decides for itself what portions of the xml data to check instead of just the one property mentioned earlier.
To force this behavior upon the parsers, we can create an interface, IExerciseParser, and then let every parser implement it:
Actionscript:
-
public interface IExerciseParser {
-
function canParse(xml:XML):Boolean;
-
function parse(xml:XML):Exercise;
-
}
-
-
public class MultipleChoiceDialectAParser implements IExerciseParser {
-
public function canParse(xml:XML):Boolean {
-
// check the xml structure
-
}
-
function parse(xml:XML):Exercise {
-
// parse the xml to a MultipleChoice
-
}
-
}
-
-
public class MultipleChoiceDialectBParser implements IExerciseParser {
-
public function canParse(xml:XML):Boolean {
-
// check the xml structure
-
}
-
function parse(xml:XML):Exercise {
-
// parse the xml to a MultipleChoice
-
}
-
}
-
-
public class FillGapsDialectAParser implements IExerciseParser {
-
public function canParse(xml:XML):Boolean {
-
// check the xml structure
-
}
-
function parse(xml:XML):Exercise {
-
// parse the xml to a FillGaps
-
}
-
}
We can now change the implementation of the ExerciseParser. We will remove the map because we will no longer be checking on a key to get a parser, but the parsers will check for themselves.
Actionscript:
-
public function ExerciseFactory(parsers:Array) {
-
this.parsers = parsers;
-
}
-
-
public function addParser(parser:IExerciseParser):void {
-
this.parsers.push(parser);
-
}
-
-
public function createFromXML(xml:XML):Exercise {
-
var result:Exercise;
-
for (var i:int = 0; i<this.parsers.length; i++) {
-
var parser:IExerciseParser = this.parsers[i];
-
if (parser.canParse(xml)) {
-
result = parser.parse(xml);
-
break;
-
}
-
}
-
if (!result) {
-
throw new Error("Cannot create exercise for the given xml object.");
-
}
-
return result;
-
}
... and configure our exercise factory before using it:
Actionscript:
-
var exerciseFactory:ExerciseFactory = new ExerciseFactory();
-
exerciseFactory.addParser(new MultipleChoiceDialectAParser());
-
exerciseFactory.addParser(new MultipleChoiceDialectBParser());
-
exerciseFactory.addParser(new FillGapsDialectAParser());
What we have achieved now is that we can add new parsers that support new xml dialects without the need to alter the code of the ExerciseFactory. All we need to is create a new parser, let it implement the IExerciseParser interface and it to the ExerciseFactory.
Additionaly, configuring the ExerciseFactory in a Prana application context is a piece of cake:
XML:
-
<objects>
-
<object id="exerciseFactory" class="ExerciseFactory">
-
<constructor-arg>
-
<array>
-
<object class="MultipleChoiceDialectAParser"/>
-
<object class="MultipleChoiceDialectBParser"/>
-
<object class="FillGapsDialectAParser"/>
-
</array>
-
</constructor-arg>
-
</object>
-
</objects>
Hope you enjoyed this. Don't hesitate to leave questions or comments. Have fun coding!
Add to Bloglines -
Digg This! -
del.icio.us -
Stumble It! -
Twit This! -
Technorati links -
Share on Facebook -
Feedburner
Just a quick note to let you know that I’ll be giving a presentation on Prana at the Dutch Flex Usergroup called Flugr on the 13th of June. So if you’re in the neighborhood (Utrecht) and would like to meet, feel free to visit the event.
Christophe Herreman is a software developer living in Belgium. He's working on high-end Flex and AIR solutions at 
Recent Comments