A buddy of mine asked me the other day if I had any thoughts on normalizing value objects coming in from various services. For example say you have at least 3 different objects that all share similar properties but aren’t quite named the same thing for convenience sake. Let’s assume that your service guy is simply assembling objects straight from the database table and using their column names rather than normalizing it for you. Here are the sample objects:
ArtistObject
{
artistName:String
artistId:int
artistGenres:Array
}
AlbumObject
{
albumName:String
albumId:int
albumGenres:Array
}
TrackObject
{
trackName:String
trackId:int
trackGenres:Array
}
And let’s say you want to normalize those incoming objects to an interface like so:
IMediaObject
{
name:String
id:int
genres:Array
}
Your first inclination may be to use an else..if statement to cycle thru the variou value object types that may be expected in a given response (assuming you are not doing low-level CRUD services and are actually leveraging services for various purposes) like so:
if (vo is ArtistObject)
{ ... }
else if (vo is AlbumObject)
{ ... }
else if (vo is TrackObject)
{ ... }
else if .... you get the point
Here is an often overlooked but extremely useful operation that will eliminate lengthy else..if loops while allowing you to cycle thru known properties to retrieve non-normalized property values.
var targetObject:IMediaObject = //whatever you are normalizing to
var vo:Object = serviceResponse.data //the object returned from your service
for (var s:String in vo)
{
//we are going to check each prop name to see if there is a match for our
//targetObject's known properties
//obviously this list will grow the more props you have to normalize
//however it only grows once regardless of the number of non-normalized VOs
if (s.toLowerCase().indexOf('name') != -1)
targetObject.name = String(vo[s]);
if (s.toLowerCase().indexOf('id') != -1)
targetObject.id = int(vo[s]);
if (s.lowerCase().indexOf('genres') != -1)
targetObject.genres = vo[s] as Array;
}
[Another quick note to myself]
I have always thought of flex developers as being categorized in two camps (at least this has been my experience). You have the:
- those who focus on mostly Flex charting and
- those who focus on everything but Flex charting.
I fall into the latter category. I just never decided to look into charts. Everytime I would take a peek at the API I would just shake my head in confusion and focus on other tasks. Why learn something new today that you can put off till tomorrow (or however that saying goes). Well a client wants charts and I am the only Flex developer on the project.
Here is a basic breakdown of what the UI is expected to have:
- comparative data showing columns, each column representing an individual item of like-type.
- unique colors per item.
- color will also indicate some status compared to a benchmark indicator.
The idea is to achieve something like this:
Whoo hoo, big deal. Just another column chart. Anywho…. so the issue was I was trying to find a way to easily color the columns based on certain conditions ergo a conditionally colored column chart.
I ran across this post (link) where someone had created a ChartItemRenderer subclass. It seems to work brilliantly, but I had to question if there was not some simpler means to do so. After much poking around I did indeed find it. Check out mx:ColumnSeries.fillFunction (link).
Doing component development is a challenging task, especially if you are trying to stick within the guidelines established by the MX framework. So frustrating is this challenge sometimes, it makes you want to tear clumps of hair from your scalp.
I found this while digging around trying to extend mx:ComboBox:
/**
* @private
*/
private function displayDropdown(show:Boolean, trigger:Event = null):void
{
if (!initialized || show == _showingDropdown)
return;
// Subclasses may extend to do pre-processing
// before the dropdown is displayed
// or override to implement special display behavior
Silly Adobe indeed.
