Config Class part 2
April 23rd, 2008
So I have been building a new Framework at Heavy. This framework is more designed oriented then the MCVC framework I was using before. The entire UI (Display) tier is built on XML similar to MXML. With that in mind I needed a way to quickly convert xml nodes into config objects. This was the next logical step from my original Config Class.
I had a few basic requirements for my XML config:
- Light weight, small, and simple.
- Be able to cache property requests to make config get faster over repeated requests.
- Be a simple drop in for other classes that were originally using my AbstractConfig class.
Here is what I came up with
dynamic public class XMLConfig extends Proxy{
public static const INIT:String = “init”;
protected var _data:XML;
protected var _cache:Dictionary;
public function XMLConfig(data:XML) {
_data = data;
_cache = new Dictionary();
}
flash_proxy override function getProperty(name:*):* {
if(_cache[name]){
return _cache[name];
}else{
var value:String = _data.@[name];
if(value){
_cache[name] = value;
return value;
}else{
trace(“Error: could not get property ‘”+name+“‘ from XMLConfig”);
}
}
}
public function clone():*{
return new XMLConfig(_data);
}
}
}
Really small right? Now I can get rid of all the getter setter BS I wasn’t really using anyways. The core of the class revolves around the getProperty override. What it basically does is looks for a cached value, if that doesn’t exist it looks for the value in the xml. If a value is there it cashes it and returns it. If not it throws an error. I was using the same proxy class system in my SettingsUtility and XML Proxy Class
Now you can do something like this:
var data:XML = <item id=“back” type=“Button” />;
// Build XML Config with test data
var xmlconfig:XMLConfig = new XMLConfig(data);
// Make new class
var instance:FooBar = new FooBar(config);
// Test sanity
trace(“type= “+config.type);
That is basically it. Very simple, lightweight and powerful XML based ConfigClass. But wait what about typing data and error checking? Wasn’t that the whole point of using the AbstractConfig Class with all the getters and setters?
Well that is the only tradeoff for this type of config object. You can’t do all the cool getter and setter data validation like you can with my other Config Class but you can add that logic into your Main class and do the validation there. Its not perfect but it with a ability to build an entire application from an external xml file I try to look past that one little issue.
April 25th, 2008 at 4:28 pm
This is series is nice. Similar to some of the ways I’ve been using E4X in Flash, but you really sweat the performance stuff like I’ve never seen.
I like it, would never occur to me to cache, but I like it.
April 26th, 2008 at 8:32 am
Performance tuning is a big part of AS 3. It is something that you should always be thinking about in you applications. These kind of XML based classes have a tendency to be on the “expensive” side so taking the proper steps to speed them up as well as make them GC (Garbage Collector) friendly will really help out in the long run. For more info on the GC you should check out this post from Grant Skinner that talks about unload issues as well as some things you can do to help optimize your code.
April 26th, 2008 at 5:19 pm
I’ve seen that Skinner article before. It reminds me of the AS2 CASA Library with their that I’m practically addicted to for as2 Dev work. They had a destroy() method and all of their classes from a Core class.
Truthfully I don’t write many apps that need such resource management. But if a framework was making it easy for me I would consider implimenting it more.
April 27th, 2008 at 9:11 pm
I ran into issues on for the MLB draft tracker where I had lots and lots of XML data in an application that needed to stay on for a few hours each visit. In those kind of cases memory management and cleaning up events is essential. I also find it good practice to implement it in what ever you do. You can never be to careful when it comes to optimization and performance.