Hi Paul, thank you for your swift reply!
On May 15, 3:42 pm, Paul Boddie <p...@boddie.org.uk> wrote:
> Sure! Just keep your observations coming! I've made a very lazy
> attempt at DOM Events support in libxml2dom,
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! =)
Browsing through the code, the EventTarget class docstring reads:
The listeners for a node are accessed through the global object.
This common
collection is consequently accessed by all nodes in a document,
meaning that
distinct objects representing the same node can still obtain the
set of
listeners registered for that node. In contrast, any attempt to
directly
store listeners on particular objects would result in the specific
object
which registered the listeners holding the record of such objects,
whereas
other objects obtained independently for the same node would hold
no such
record.
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? 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.
Furthermore, your code finds the bubbling route with the line:
bubble_route = target.xpath("ancestor::*")
That xpath method is a libxml method right?
> (...) although I find these things quite hard to
> figure out with the usual vagueness of the specifications on certain
> crucial implementation-related details (and that there's a mountain of
> specifications that one has to navigate).
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.
> 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?
> It occurs to me that various PyQt- and PyKDE-related bindings might
> also provide some exposure to DOM Events, although I had heard that
> WebKit, which should have support for lots of DOM features, exposes
> some pretty useless interfaces to languages like Python, currently.
> The situation with Mozilla and PyXPCOM may well be similar.
PyKDE is off-limits because it's unix only while I'm trying to be
cross-platform. PyQT is interesting. Very. Further investigation is
required. =)
Manu
--
http://mail.python.org/mailman/listinfo/python-list
