Ah, never mind - I've figured it out. The method which created a new DOMNode
from an XMLNode used a for...in loop to copy properties from the XMLNode to
the DOMNode. This was done to prevent compiler errors from assigning Flash 8
properties when compiling for Flash 7, and to keep it open for future
additions to the XMLNode class.
The problem was caused by copying function properties as well. Excluding
function types fixed the issue.
Cheers,
Scott
On 01/12/06, Scott Whittaker <[EMAIL PROTECTED]> wrote:
Hi guys,
I'm having a curious and somewhat annoying problem using overridden
methods in a subclass. What I am trying to do is extend the XML class into a
new XMLDocument class and the XMLNode class into a DOMNode class in order to
add some useful extra methods such as getElementByID, getElementsByTagName
and the ability to produce a customisable object map of any DOMNode. All of
this is working for the most part.
The reason I am extending the XML classes in this way is so I can get the
most out of the speed and functionality of the intrinsic methods, remain
compatible with other scripts designed to work with regular XML objects, and
take advantage of my custom methods for accessing and manipulating XML
without going for a heavyweight solution like XPath.
The constructor to create an XMLDocument composed of DOMNodes is like
this:
public function XMLDocument( source:String ) {
super();
parseXML( source );
}
public function parseXML( source:String ):Void {
super.parseXML( source );
var document:DOMNode = convertNodes( this.firstChild );
this.firstChild.removeNode();
this.appendChild( document );
}
So the XMLDocument is initialised with the default constructor and any
source string is passed along to the parseXML method to build the regular
XML structure. Next, the childNodes are converted from XMLNodes to DOMNodes
using the convertNodes recursive method. Actually the XMLNodes are not
converted as such - the information within them is used to create new
DOMNode instances and the structure recreated with the
DOMNode.appendChildmethod (which accepts a DOMNode argument and simply passes
it along to
super.appendChild ). Finally, the original XML tree is removed and
replaced with the new DOM tree.
The resulting XMLDocument seems to be created intact and all the XML,
XMLNode, XMLDocument and DOMNode methods mostly seem to be working as they
should. The first issue I discovered was when I selected a node, duplicated
it with cloneNode, and tried to use a DOMNode method on it - which failed.
Debugging showed me that the overridden cloneNode method was not being
called - it was using the superclass' cloneNode method. Further
investigation showed that while a DOMNode created directly through an
XMLDocument instance using createElement would call the overridden methods
correctly, but nodes already on the XMLDocument accessed with any method
would use the superclass' methods instead (as if they were plain XMLNodes) -
even though they were able to successfully call DOMNode methods.
To illustrate this, I created an attachNode method on DOMNode to proxy to
the appendChild method to trace the execution path:
public function attachNode( newChild:DOMNode ):Void {
trace( "DOMNode.attachNode" );
this.appendChild( newChild );
}
public function appendChild( newChild:DOMNode ):Void {
trace( "DOMNode.appendChild" );
super.appendChild( newChild );
}
What happens is that the attachNode method is called (which proves the
object really is a DOMNode and not an XMLNode) but the overridden
appendChild method is not called - despite it being called internally! And
like I said before, an element created with XMLDocument.createElement does
call the overridden method. Bizarre.
Does anyone have any idea what is going on here? Is this something
specific to XML, any intrinsic objects, or some weird inheritance bug that
can affect any class? Is there a solution? Or am I stuck with having to
rewrite the whole set of XML methods from scratch and avoiding superclass
methods altogether?
Thanks,
Scott
_______________________________________________
[email protected]
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
