Re: DocumentFragment and load/loadXML

On Thu, 2002-10-31 at 21:55, Dominic Chambers wrote:
> 
> 
> 
> > On Tuesday, 10/29/2002 at 09:11 EST, "Dominic Chambers"
> > <dominic.chambers@bigfoot.com> wrote:
> > > Therfore, shouldn't the DocumentLS interface be implemented by
> > > DocumentFragment objects also?
> >
> > I think not. The meaning and usage of DocumentFragment has changed
> > somewhat as the DOM has evolved, and the quoted paragraphs should not be
> > taken overly literally.
> >
> 
> Yes I do see you point. I myself never use DocumentFragment normally, but
> was hoping to offer a sensible way to allow loading into a node.
> 
> > In particular: Every DocumentFragment exists in the context of a specific
> > Document node, which carries the factory methods for creating more nodes
> > compatable with that DocumentFragment. Since Load can be considered
> > another kind of node factory, I think it makes perfect sense for Load to
> > be associated with the Document rather than the fragment, and Save would
> > remain on the Document for reasons of symmetry.
> >
> > It is certainly desirable to be able to load XML source into the context
> > of an existing Document (rather than loading into a new Document and
> > having to import/adopt them), and quite possibly to insert them into a
> > DocumentFragment in the process of doing so... but as long as the APIs
> > support that operation I don't think the methods themselves need to be
> > duplicated on DocumentFragment.
> >
> 
> Yes, I agree, loading XML into nodes should be possible without creating
> a new Document and importing. The problem as I see it, is that there are
> two ways of using Load and Save: the easy way and the hard way. This
> makes sense since Load and Save has so many nice features when you go
> the full distance and create a DOMBuilder.
> 
> But, the easy way does not allow users to import or export directly from a
> node, which is a common desire, and is already provided by both IE and
> Mozilla using the proprietary innerHTML method. This leaves the hard way
> of achieving this conceptually simple task.
> 
> For example, node.innerHTML = xml, would be written as:
> 
>     var domBuilder = document.createDOMBuilder(
>         document.MODE_SYNCHRONOUS);
>     var inputSource = document.createDOMInputSource();
> 
>     inputSource.stringData = xml;
>     domBuilder.parseWithContext(inputSource, node, DOMBuilder.REPLACE);
> 
> Notice that in this example we are not using entity resolvers, error
> handlers,
> feature determination, character decoding, XML base, asynchronous
> download, or any of the good stuff that Load and Save offers the more
> advanced
> user.

Note that the inputSource could be your own object and does not have to
be necessarily one created with createDOMInputSource. Yes, your example
does not take into account the parameters for the configuration, but
this is the advantage of a DOMBuilder compared to solutions like
innerHTML.

> So there seems to be a disparity between a synchronous uri or string load
> into a
> document, and the same thing into a node. The node is definately a second
> class
> citizen in this model.

This has been the case in the DOM model for a while. Only documents can
create nodes for example.

> Is there a reason for this disparity, and does it have anything to do with
> the fact that
> IE currently provides load and loadXML for documents, but not for nodes?

DocumentLS was indeed introduced to match a current set of
functionalities in web user agents.

> Would
> it change anything if these methods (or some other similar methods) were
> made
> available for nodes and they never supported it?

And each Node would have a different set of parameters? or would you
only support the parameters on the DOMBuilder of the Document and then
the Node is only reusing them? I don't think it would make sense to
support this method on one set of Nodes and not an other either.

Philippe

Received on Monday, 4 November 2002 12:05:45 UTC