On 15 Mai, 18:27, "Emanuele D'Arrigo" <man...@gmail.com> wrote:
>
> I just had a look at libxml2dom, in particular its events.py file.
> Given that we are working from a standard your implementation is
> exceedingly similar to mine and had I know before I started writing my
> own classes I would have started from it instead! =)
Another implementation is probably a good thing, though, since I don't
trust my own interpretation of the specifications. ;-)
> Browsing through the code, the EventTarget class docstring reads:
[Long docstring cut]
> Naively, I implemented my EventTarget class storing its own listeners
> rather than global ones. Nevertheless, I'm not quite understanding
> this issue. 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;
therefore, storing listeners on such instances is not very helpful
because the expectation that you will automatically see previously
added listeners on a node will not generally be fulfilled. With pxdom,
it may be a different situation, but libxml2dom is constrained by the
behaviour of libxml2: I don't attempt to check node equivalence and
then expose the structures representing a single node using a single
object; I generally try and instantiate as few Python objects,
wrapping libxml2 structures, as I can.
> I have a glimpse of understanding that if the
> DOMImplementation keeps EventTarget and Nodes (or Elements? which
> entity is supposed to support Events?) separate this might be
> necessary. But beside the fact that it's just a fuzzy and potentially
> incorrect intuition, I seem to think that the appropriate way to
> proceed would be for the DOMImplementation to provide a Node class
> that also inherits from EventTarget. In so doing the listeners would
> be immediately accessible as soon as one has a handle to a Node.
The libxml2dom.svg module has classes which inherit from EventTarget.
What I've tried to do is to make submodules to address particular
formats and document models.
> Furthermore, your code finds the bubbling route with the line:
>
> bubble_route = target.xpath("ancestor::*")
>
> That xpath method is a libxml method right?
I use libxml2's XPath support exposed via libxml2dom.Node.
> Indeed there is some vagueness in the W3C recommendations and the
> various documents offer very little redundancy with each other but
> require you to be knowledgeable about them all! I'm managing to piece
> together the pieces of the puzzle only after a couple of day having an
> in-depth read-through of DOM, DOM Events and a little bit of XML
> events to see how it all works in practice. XML events is also what's
> prompting me to think that Node/Elements classes of the implementation
> should also inherit from EventTarget as they can all be event
> targets.
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.
> > 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...
>
> Before I can comment I'd like to better understand what you are aiming
> for with libxml2dom. It seems to be providing some kind of conversion
> services from the xml structure generated by libxml to a dom-like
> structure (implemented by pxdom?).
> Is that correct?
Yes. The aim is to provide a PyXML DOM API on top of libxml2
documents.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
