I'm encountering this very odd XML issue. First off, here's the code.
override public function get datasourceNode():XML
override public function resetImportTypeNode():void
The class that this code is in is intended to be a sort of wrapper around an XML object that stores some settings in my application. I'm attempting to shield the users of this class from the specifics of the XML, should they change in the future. As you can see, this is a subclass, and these overriden methods are intended to be implementations of "abstract" methods in the superclass. I have two different users of this class that both need to use these methods, but with slight differences in the underlying XML, thus this architecture.
Here's what's happening: (*Note: Utils.isEmpty is just a utility method to evaluate the emptyness of many different object types)
The resetImportTypeNode method is called during initialization, and is meant to wipe the current contents of configXML.scorecards (configXML is the underlying XML object which the class is a wrapper of), and add a new fresh configXML.scorecards, which is required for most of the other functions of the class. The purpose of datasourceNode is to get the configXML.*.datasource node (* varies between subclasses), additionaly creating it if it does not exist.
However, I'm finding that when my code hits resetImportTypeNode, with an fresh configXML (all it has is the root node which happens to be <datamapping/>)... after the "delete..." line, the XML is unchanged, as expected. Then (and this is where my mind is blown), after the "append scorecards node" line, the value of configXML is now:
Yeah, what!? I finally managed to isolate this problem to the datasourceNode method. When I comment it out, I get:
as expected. But here's the crazy thing... as verified in the debugger, datasourceNode does not get called AT ALL before that point. Also, if I change <scorecards/> to some nonsense value, like <blah/>, it works as expected. So, best I can figure, SOMEHOW, this "append scorecards node" line is triggering some behind the scenes call to datasourceNode (it never gets hit in the debugger...), which is somehow adding not one but TWO mysterious <datasource/> nodes to the <scorecards/> node. Nevermind the fact that that doesn't even match the logic of the datasourceNode method, we've obviously abandoned logic long ago with this issue.
Here's my only guess as to what's going on behind the scenes: there are several concrete implicit getters/setters on the superclass that reference the datasourceNode getter. I've noticed when debugging, that prior to the "append scorecards node" line, they all have an "<exception thrown>" value, and when examining the details in the debugger, that value is "TypeError: Error #1088: The markup in the document following the root element must be well-formed.". This seems to imply that these implicit getters are "evaluating" themselves behind the scenes, in which case it makes sense that they would "show" that exception at that point in the execution. At that point the value of configXML = <datamapping/>, just the root element. Then, after the "append scorecards node line", these "<exception thrown>" values change to "TypeError: Error #1034: Type Coercion failed: cannot convert XMLList@9d43ac1 to XML.". Following the logic that there is some behind the scenes evalutation of these getters going on, one could then extrapolate that they are re-evaluating themselves (which would call datasourceNode), now finding that the scorecards node IS present, and perhaps the first evaluation is successful, and adds a <datasource/> node to <scorecards/>, as does the second evaluation, but then the return, and thus all subsequent evaluations throw the Error #1034 (datasourceNode returns an XML object, but we now have an XMLList of 2 <datasource/> nodes).
If you've managed to bear with me through all of this, I thank you. My understanding of what is actually happening here is extremely tenuous. I really hope somebody has a clue what is going on. I'm thinking that the takeaway lesson here may be that mixing a single XML instance with multiple nested implicit getters is dangerous business. If what I think is going on actually is going on, that seems a bit problematic.