I am not sure my approach is the best, but in an almost similar case,
I chosed to clone the xml tree using a custom Node class.
This class only implements the the methods I needed (getAttribute,
setAttribute and getElementsByTagName).

The big (imho) advantage of this approach is that the performance hit
is only present for peoples using IE (of course, you don't clone the
xml document if the user is using a browser which is not IE).

Another advantage is that the code is pretty clean since you only have
to modify the way the XML document is retrieved.
E.g. having something like this:

var docRoot = ie?new CustomNode

I am aware this solution is far from perfect, but I hope it can help
you to find a new approach.

And if somebody knows a better solution, please do not be affraid to
post it :o)


On Dec 9 2008, 10:37 pm, donundeen <donund...@gmail.com> wrote:
> Hi,
> I know this issue has been covered before, but maybe you all can help
> me find a new angle on a solution:
> I've been developing this nifty little javascript-based xml editor,
> that uses a schema to dynamically generate the form. Edits to the form
> update the instance xml as you type. The best part about it is that
> you can create special schema types, that can have all sorts of
> validation and special input elements. Sorry, not explaining it to
> well, but:
> It relies heavily on extending xml elements, based on the related
> schema type, to add the validation and display functions. It also
> extends the elements so that the schema doc elements can access the
> instance xml elements, the instance xml elements can access the form
> elements, etc. And I use xpath a lot to traverse for example the
> schema doc, then I use those extensions to cross over to the xml
> element, etc.
> It works quite well in firefox, and allows a nice architecture that's
> easy to extend. Of course you can tell where this is heading...
> totally doesn't work in IE, because you can't extend the xml elements.
> IOW, something like this:
> var someElem = doc.createElement("bar");
> Object.extend(someElem, myMethods);
> someElem.doThis();
> var myMethods = {
>         doThis : function (element){
>                 alert("in DoThis");
>         }
> }
> Works in Firefox, not in IE.
> This topic's been covered, as I've read.
> However, it seems to me like this kind of pattern; needing to be able
> to "see" an element from the context of another element, would be
> something other people would want to accomplish.
> All the fancy validation and display generation, currently within the
> xml element, I could move out. However, at the basic level, I still
> need to :
> 1. access some nodes via xpath
> 2. from those nodes, access related nodes in other documents.
> I'm wondering if anyone else has tried to accomplish this same thing,
> and how they did it?
> Off the top of my head, I can imagine some hacky-solutions, like:
> - generate a unique ID for each element, then maintain the linkages
> via attributes containing the IDs of related elements. That doesn't
> seem terribly elegant, but would work.
> Does anyone else have a better approach. I'm all ears.
> thanks for your time,
> don
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to