[Webkit-unassigned] [Bug 60269] [Windows, WinCairo] Implement ability to add C++ event listeners to html dom elements and dom window

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=60269





--- Comment #11 from Anthony Johnson <anthony.johnson at flexsim.com>  2011-05-05 15:10:31 PST ---
(In reply to comment #10)
> (In reply to comment #7)
> > > I'm wondering if there might be a way to get rid of the helper class you created, and have this functionality be part of the IDOMEventListener* directly?
> > 
> > I don't see a possibility right now. Since it seems to me like the design is such that the user accessing the API would only go through the COM interface, they would not have access to the definition of WebCore::EventListener, and in order to override WebCore::EventListener::handleEvent(), they'd need access to the class definition.
> 
> The more I look at this, the less I understand the design of the listener handling.  What is the point of an IDOMEventListener, if it can't be round-tripped through WebCore such that its 'handleEvent' method ends up getting called?
> 
> Are we just not understanding how this is meant to be connected to WebCore?

First, please realize that a lot of this was already implemented with empty stubs when I got to it. I'm just trying to fill it out like I imagine the original guy would have. I think the idea is that an end user would only see the COM interfaces, i.e. IDOMEventTarget, IDOMEventListener, presumably so that the interfaces can be accessed via non-c++ functionality as well as c++ functionality. So, if I as an end user just see the interface definitions, then in order to get the stuff to call my handleEvent() method, I essentially have to define my own class that implements the IDOMEventListener interface:

class AnthonyEventListener : public IDOMEventListener {
  handleEvent(IDOMEvent* e);
  ...
};

Then when I need to attach to an element event, I create an instance of AnthonyEventListener, then pass my instantiation to IDOMEventTarget::addEventListener(). At that point I assume that when the event is fired, my handleEvent() method will be fired.

Now, in order for the implementation to do a direct pass-through from WebCore to my class handleEvent() method, my class definition would also need to inherit from WebCore::EventListener.

class AnthonyEventListener : public WebCore::EventListener, public IDOMEventListener{
  handleEvent(WebCore::ScriptExecutionContext* s, WebCore::Event* e);// EventListener override
  handleEvent(IDOMEvent* e); // IDOMEventListener override
  ...
}

There are a few issues with this. First, the end-user would need to sub-class WebCore::EventListener, which by design they should not have a definition of (they just see the COM interfaces). Second, IDOMEventTarget::addEventListener() would have to assume that the IDOMEventListener passed would also be a sub-class of WebCore::EventListener, because it needs to translate it into that in order to call WebCore::Node::addEventListener(), which isn't very good design and would break for non-c++ COM bindings.

So, it seemed to me that the best way to do it would be to create a go-between class within the COM implementation, that handles the translation from IDOMEventListener to WebCore::EventListener. The class inherits from WebCore::EventListener, so it can be added using WebCore::Node::addEventListener() and its handleEvent() method will be properly called, and it also holds a pointer to an IDOMEventListener (the user's implementation), so that it can pass the handleEvent to the IDOMEventListener. In this way, the end-user can just worry about implementing his own IDOMEventListener interface, and the go-between will automatically handle the COM-to-WebCore translation and back.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.