This package contains a DOM implementation build on top of the google base classes. This dom implmentation supports firing events when the dom structure or attributes change. It also enforces unique IDs on elements.


The parser and DOM could be changed to use more built-in support. A survey of that support:


Mozilla supports at least some Dom Level 2 mutation events. In addition Element prototype can be modified and the parser will then use that definition. Safari also supports mutation events as of 1.3?

IE does not support mutation events. In addition, you cannot change the prototype for XML elements. In fact, you can't event do something like:

element.setAttribute = someOtherMethod;

The IE DOM implementation does not seem to be a pure js implementation or even a js wrapper around something.

Both Mozilla and IE support xpath to some degree. Not sure about others.

Some approaches to consider:

1. Use the browser parser to parse the XML, (using SAX parser hopefully?) then convert that to our DOM. Is this any faster than parsing ourselves? Probably as the parser is natively implemented.

2: In browsers that support it use their dom directly and either use their mutation events or, since those are maybe overkill and akward, change the prototype to to fire the events that we need. For example change setAttribute() to do some eventing then call super.setAttribute() which was saved someplace else.

Using the browser parser + dom gives us a bunch of things, including efficiency, schema checking, etc. However it also introduces complication as browser implementations diverge. DOM Level 2 events don't seem well supported and should probably be avoided. (Also the DOM level 2 event spec is kind of annoying and hard to work with anyway)




Example code in mozilla:

Element.prototype.originalSetAttribute = Element.prototype.setAttribute;

Element.prototype.setAttribute = function(){
	event out
	this.originalSetAttribute(...);

}


This might change not just XML elements but HTML ones as well, but that should be ok hopefully.

At the very least we can use the browser SAX parser to parse out our stuff, or the DOM parser then run through and convert to our DOM.

If we can only load code specific to that browser it should save some code size. However if we don't do that it could actually increase code size as we include different code for different browsers. The best might be to have a mozilla-specific file, an safari one, an IE one, etc, and load the one we want as needed, although that does make some organization stuff harder.

The advantage of what we have now is that it is almost totally independent of the browser and will work for any browser the same. We should do some performance testing to see how much of a gain using the browser functionality is.


At the least we probably want to distinguish between elements that need to report events and those that don't. It's only documents in the DocumentContainer that need to event out.

For example if we have the following:

<xmodify>
	<append select="/row">
		<ui:row/>
	</append>
</xmodify>

We will clone the <ui:row> element and append it to every row in the UI Dom. The original document does not need to event out at all!

One way to handle this would to have importNode() in our document and createElement() in our document create/import nodes that event out, but use the default parser for original input files. SO the workflow there would be:


Parse the document via browser parser.
Perform the append
For each original row, clone the <ui:row/> element and stick it in the UI doc. At this point, either in the clone or import make the element DOM Mutation event aware.