Re: Implementation question

Emanuele D'Arrigo wrote:
> I think that matches both my understanding and my description: there are 
> two structures of objects, one implementing the DOM interface and one 
> that is related to it but implements functionality directed toward the 
> presentation of the document. What's so not at all the same?

OK, I guess I must have misunderstood the question, then.  The rendering 
tree has to be separate from the DOM, because there are boxes that have 
no corresponding DOM nodes, and vice versa....  So you really can't do 
it all (DOM API and rendering) using a single tree data structure.

> I understand the difference there is between an interface and a class, 
> and I understand that the DOM specifies interfaces rather than classes. 
> But eventually those interfaces are implemented somehow and they are 
> likely to be classes.

Sure.

> In this context I assume that a DOM implementation 
> is likely to have a Document class, an Element class, an Attr class and 
> so on. Is that so unlikely? I.e. I'd imagine that this page 
> <https://developer.mozilla.org/en/DOM/element> in Gecko's reference 
> refers to an underlying DOM Element class implemented in C++.

Sort of.  This documents the properties present on all objects in the 
Gecko DOM that implement the DOM Element interface.  There is an 
nsGenericElement class which any particular element instance is a 
subclass off, but no instances of nsGenericElement itself are ever 
created; just subclasses of it.

Similar for documents; there's an nsDocument class, but no nsDocument 
objects are ever created, just subclasses.

> What you mention is part of my sentence: "Do implementations subclass 
> the Element class and override Document.createElement() to create the 
> appropriate object?"
> 
> In this context I was asking if an implementation would be likely to 
> have element classes such as HTMLElement, HEADElement, BODYElement, 
> TITLEElement and so on for each XHTML or even SVG tags, all inheriting 
> from an  Element class that implements the DOM Element interface.

That depends on whether the implementation wants to implement the SVG 
and HTML DOMs.  If yes, then probably yes.  If not, then probably not.

Note that in Gecko's particular case, for various implementation 
reasons, nsGenericElement does not in fact inherit from the DOM Element 
interface (though various subclasses of nsGenericElement do).

> Good, once you have that, how do you render it to screen? Does that tree 
> structure also implement all the rendering related functionality?

I think doing that would be very very difficult.  See above.

> Does it handle any tag-specific logic?

See above.

> Or is it a repository of data accessible by something else that does layout, rendering and so on?

False dichotomy, basically.  See above: the DOM has various tag-specific 
logic and layout is done on a different data structure.

I believe the same is true of webkit, for what it's worth, so it's not 
just Gecko.

>     The form this takes depends on the binding language;
> 
> Why do you say that it depends on the language? I'd say it's dependent 
> on the application itself. Or are you alluding to the possibility for 
> the DOM to be implemented in a non Object-Oriented framework?

I'm just saying that precisely how one goes from an Element that is 
known to be an HTML <a> element to HTMLAnchorElement depends on the 
language one is accessing the DOM from.  In your typical JS binding it 
looks like this:

   htmlAnchor = element;

In your typical Java binding it looks like:

   htmlAnchor = (HTMLAnchorElement)element;

In Gecko's C++ XPCOM bindings to Gecko's DOM implementation it looks like:

   nsCOMPtr<nsIDOMHTMLAnchorElement> htmlAnchor =
     do_QueryInterface(element);

That sort of thing.

> Ok, I think I'm gathering that my questions were too much out of 
> context. Sorry about that.
> 
> Everything I asked is in the context of an application that doesn't  
> just load an xml/xhtml/svg document in memory but also does something 
> practical with it, i.e. visualise it like a browser does.

OK, sounds like you'd need to implement more than just DOM Core, then.

> In this context I was asking if an application is likely to populate a 
> DOM tree and then use it purely as a repository of data, or if the 
> objects in the tree implement much more than just the DOM interfaces and 
> are capable to, say, render themselves. It appears that at least in the 
> case of Firefox the Content Model is closer to a repository of data than 
> an presentation-capable module. Don't you agree?

Correct, for the reasons above: you need to have rendering objects that 
don't correspond to elements.

-Boris

Received on Thursday, 21 May 2009 23:24:16 UTC