Re: Optimizing and XMLC application

It would be an interest comparison to see how long it takes to building the
original vs doing the copy.  However avoinding the copy is ideal.

Someone once had a very cool suggestion that I was interested in
implementing (but never got to) that address just this problem.

The output of the DOM is done by recursively traversing the DOM,
outputing the begin tag at an element, recusively outputing it's
children, the outputting the end tag.  The lazydom adds some added
book keeping to avoid expanding unexpanded nodes of the tree.

The idea would be to link DOMs in some manner, so that the output process
would render a subtree from another DOM  in place of subtrees of the
main DOM.  The elements could be identified by id, so that that an
element id in one DOM would map to an element id in another DOM.

Will doing this in a general, clean way is a bit of work, you might be
able to hack something specific to you project without to much complexity.

Mark

David Corbin <dcorbin@xxxxxxxxxxxxxx> writes:
> Now the trick is, HOW.  Inserting a pre-generated DOM at run-time is not
> too difficult, but I still pay the price of duplicating the DOM.  For this
> to be a really big gain, I need to be able to spit out "raw HTML" in the
> middle of an existing DOM.  The last time I asked about this (for entirely
> different reasons), I got back a "it can't be done", I think.