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 <[email protected]> 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 [email protected] 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 -- http://mail.python.org/mailman/listinfo/python-list
