FlexOOP

A little while back Nate Beck and Marty Mickelson set up the Bug Quash event to promote users to give back to the Flex SDK that they all work with each day by submitting bug fixes. Just from working with Flex everyday, we’ve probably all come across at least one bug that had us beating our heads against the wall thinking that we were doing something wrong, when there was actually something a little wonky with the Flex SDK. As Flex is open source, it allows for anyone to submit a patch for review by Adobe, and, once you set up your local environment (and set up your sandbox account), there’s really no good excuse not to try to fix something. Plus, it helps you to understand the code you’re working with at a more fine grained level, rather than just taking for granted that Flex “just works”.

I attended the first BugQuash, but only late in the day, so I didn’t get to fix anything at the time. Still wanting to fix a bug, I decided I’d check out the bug listings of at the Adobe Bug System. As I’d worked with the date functions in Flex quite a bit for my Flex Date Utils library, I figured I’d try to find something to do with dates in the bug base. In checking through, I came across this little one. I wanted to take something that wouldn’t be too crazy to accomplish for my first fix, but was at least useful to add.

I submitted the first patch back in April (a month or so after the BugQuash finished). It took me a little while to get my environment set up (Nate gave a little video demonstration of how to set up your environment here so check it out if you’re thinking of contributing), but once I did, it was pretty painless. I got some feedback (I’m not sure whether it was a user or someone at Adobe) on the patch and made the suggested changes, resubmitted back in June, and today my patch just got approved Turnaround wasn’t too bad considering that Flex 4 is in beta along with Flash Builder, ColdFusion Builder, CF9, and everything else going on at Adobe lately.

Now I just have to figure out which one I want to work on next. Plus, check out my “Bug Quash Badge”…also created by Mr Beck. It links up to the JIRA and queries for the number of bugs you have “quashed”. Excellent!

Well, maybe not completely unusual behavior, but I figured I would document my findings for others anyway.

ColdFusion allows managing of XML documents with relative ease. From the dot notation for traversing an XML document to the various functions to manipulate the document, just about everything is pretty simple when using ColdFusion. Recently, however, I came across an issue with using XMLSearch() It’s probably more of my (previous) understanding of the function call itself rather than it not working correctly, but it still seems a little unusual behavior to me.

I had an XML document that parsed fine.

<cfset INST.parsedData = xmlParse( INST.config ) />

From here I did an XMLSearch for a certain type attribute in my parsed document:

(I grab the first item of the array and set it back to itself so I’m not creating an extra temp variable. The @type is always present in the file so no error will be thrown)

<cfset INST.subObject = xmlSearch( INST.parsedData, "//object[ @type= '" & INST.eachType & "']/") />
<cfset INST.subObject = INST.subObject[ 1 ] />

From here, I wanted to grab a specific item from INST.subObject, but doing the following would always return all of the property nodes with identity=”true” rather than just those specific to the INST.subObject variable

<cfset INST.identityProperty = xmlSearch( INST.subObject, "//property[ @identity= 'true']") />

I guess that the INST.subObject is actually just a pointer of some sort to the original document and when passing the xmlDoc argument into xmlSearch, it then uses the whole original document to perform the actual search.

The solution isn’t too difficult, but may not be completely apparent at first. You just have to create a new xml document of the returned data, thus wiping out any references to the original parsed XML document.

<cfset INST.subObject = xmlparse( tostring( INST.subObject[ 1 ] ) ) />
<cfset INST.identityProperty = xmlSearch( INST.subObject, "//property[ @identity= 'true']") />

INST.identityProperty will now contain the one node within INST.subObject that has an attribute “identity” of true (rather than returning all nodes in the original document with attribute “identity” of true).