Re: Implementation question

2009/5/21 Boris Zbarsky <bzbarsky@mit.edu>

> Emanuele D'Arrigo wrote:
>
>> This matches the second option in my original post: "(...) Or is the DOM
>> tree created out of the input file and then a parallel, specialised,
>> structure is instantiated and appropriately kept in sync with it? (...)".
>>
>
> Not at all.  The frame tree in Gecko is basically the CSS box tree. It's
> not the same as the DOM tree because the two are quite non-isomorophic (e.g.
> display:none elements or comments are not present in the box tree).


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?


> I'm not quite sure what your original post was about, actually.  There is
> no such thing as "the Element class",


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. 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++. Wouldn't that be a safe bet to make?


> I'm not sure what "the appropriate object" is, and I'm not sure what the
> separate data structure you describe is actually used for.


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.


> What is true is that one must have a tree structure and that the objects in
> this structure must implement the DOM interfaces appropriate for them.


Good, once you have that, how do you render it to screen? Does that tree
structure also implement all the rendering related functionality? Does it
handle any tag-specific logic? Or is it a repository of data accessible by
something else that does layout, rendering and so on? It appears that at
least in Firefox the latter is the case: the DOM tree holds the document and
that data is used by the Frame tree. That is the information I was looking
for. Is this not correct enough for you?


> 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?


> the precise list of interfaces implemented for any given object depends on
> the object and on which DOM specs one is trying to support.


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.

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?

Manu