DOM implementation

[Emanuele D'Arrigo]

Hello Paul, sorry for the long delay, I was trying to wrap my mind
around DOM and Events implementations...

On May 15, 7:08 pm, Paul Boddie <p... at boddie.org.uk> wrote:
> Another implementation is probably a good thing, though, since I don't
> trust my own interpretation of the specifications. ;-)

Tell me about it. In general I like the work the W3C is doing, but
some things could use a little less freedom and a little more clarity.
=) But then again, maybe it's for the best to leave things as they are
so that we can figure it out for ourselves.

> > Why shouldn't the listeners be stored directly on the EventTarget?
>
> One reason for this might well be due to the behaviour of libxml2 and
> libxml2dom: if I visit the same node in a document twice, obtaining a
> node instance each time, these two instances will be different;

Mmmm.... I don't know the specifics of libxml... are you saying that
once the object tree is created out of an XML file, requesting twice
the same node object -does not- result in a pointer to the same
instance in memory? How's that possible?

> The libxml2dom.svg module has classes which inherit from EventTarget.

And what does the EventTarget inherit from? Or are those classes
inheriting
from both Nodes and EventTargets?

> What I've tried to do is to make submodules to address particular
> formats and document models.

I think the issue to consider there is that the DOM does not restrict
a document from being a mush-up of multiple formats. I.e. it should be
possible to have XHTML and SVG tags in the same document. As long as
those modules work at element/tag level and do not obstruct each other
I think you are on the right track!

> I think that if I were to expose an event-capable DOM, other than that
> provided for SVG, I would just have a specific submodule for that
> purpose.

Ultimately I found it moderately easier to modify pxdom with the
intention of releasing "pxdome", a fork of pxdom. Monkey-patching
pxdom seemed to be a little too tricky and prone to error to create a
separate module.

> > > One of my tests tries to exercise the code, but I might be doing it
> > > all completely wrong:
> > >https://hg.boddie.org.uk/libxml2dom/file/91c0764ac7c6/tests/svg_event...

I had a more in-depth look after having spent the weekend trying to
wrap my head around all sorts of implementation issues.

My understanding, also after a few exchanges in the www-dom at w3.org
mailing-list, is that initialization of an event can happen wherever
you feel like doing it, except in Document.createEvent(). I.e. it
could be a method on the event itself or an external function. In your
code however, I believe the initialization method should be
initMouseEventNS() rather then initEventNS() and the namespace for DOM
3 Events should be -None-. Between the two implementations the first
one seems to be more aligned with the DOM documentation.

The way I'm doing it is that I invoke Document.createEvent(eventType),
I initialize the resulting event in part manually and in part with
type-related default settings and I finally use
Document.pxdomTriggerEvent(event) to create a propagation path and
iterate through its targets. I.e.:

def _trigger_DOMSubtreeModified(target):

  relevantTargetTypes = (Node.DOCUMENT_NODE,
Node.DOCUMENT_FRAGMENT_NODE,
                         Node.ELEMENT_NODE, Node.ATTRIBUTE_NODE)

  if target.nodeType not in relevantTargetTypes:
    return

  if target.ownerDocument:
    event = target.ownerDocument.createEvent("MutationEvent")

    event._target = target

    target.ownerDocument.pxdomEventDefaultInitNS(None,
"DOMSubtreeModified", event)
    target.ownerDocument.pxdomTriggerEvent(event)

Notice that I'm currently keeping this function as a loose function
but it could very well be placed as a method in the Document class or
in each relevant classes. I'm not sure why one option would be better
than all others and the DOM doesn't specify it.

The dispatch of the event to each target on the propagation path is
also a matter of implementation. In the discussion in www-dom three
options have emerged: 1) the Document node establishes the propagation
path and iterates through the targets listed to dispatch the event to
each 2) an unspecified, external object does the same job 3) the
propagation path is established, stored on the event and each event
target is responsible for recursively dispatching the event to the
next target if propagation hasn't been stopped.  Apparently an earlier
version of Mozilla's Gecko used option 3 but they eventually switched
to option 1. Again, it's unclear in what circumstances to use one
option or the other.

What I don't know at this time is how to merge all this with the
specific file formats such as SVG and HTML. I.e. in an SVG example, do
I create a GroupElement(Element) class and I override the
Document.createElement() method to create an instance of it any time a
<g> element is found in the input file? Or do I first create an
application-neutral DOM tree out of the input file and I then
instantiate a parallel application-specific structure, holding the
objects that provide methods to actually draw and group shapes? If I
get an answer from www-dom I'll report it here...

Manu