Hi Thiwanka, Thiwanka Somasiri <asthiwa...@gmail.com> wrote on 02/18/2011 04:12:27 PM:
> Hi Michael, > I was studying the facts you were asking me to follow and > got an understanding about what Events, event capture, event > bubbling, etc are [1][2] and went through the spec for EventListener > and EventTraget interfaces. Also I noticed > the DocumentImpl and NodeImpl classes are having event processing > aspects and they represent the root of the document of the tree and > structure of the tree(nodes) respectively. In [2], it depicts how an > event occurred is dispatched down the tree explaining event capture > and event bubbling. But I am not clear how this "dispatching event" > is happening and need some help from you to figure it out. I expect the dispatch for the LSParser to be much simpler than the general case. Unlike the DOM tree which has ancestor nodes, there's only one EventTarget (i.e. the LSParser) here. > The W3C specification indicates, that events supported by > asynchronous LSParser objects are LSLoadEvent and LSProgressEvent. > So, are these the only Event classes that we have to implement > (in org.apache.xerces.dom.events package) in order to support async LSParser? That's correct. > I also have an issue of LSLoadEvent. In the spec it clearly > describes the asynchronous property of LSProgressevent with an > example. But I cannot imagine such an example where LSParser behaves > asynchronously with LSLoadEvent because, LSLoadEvent is intended to > signal the completion of a document load where it does not imply an > async property(for example, if it signals the progress of loading > the document we can assume that it is async as it was in > LSLoadProgressevent). I want to clarify this too(anyway I may be > wrong and may have misunderstood the case.) The process is asynchronous. When you call parse() on an asynchronous LSParser it returns immediately with null. At this point the Document may not have been constructed yet. At some point later when the parser has completed its work, an LSLoadEvent is fired at the EventListener which contains the completed Document that has finished loading. The thread which called parse() is free to do other work while the parser is busy (on another thread). > I will go through the DOM implementation some more in > upcoming days and if I have to cover any other specific areas > related to the project, I hope you will guide me through. > > [1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-Event > [2] http://www.w3.org/TR/2010/NOTE-xml-events2-20101216/ > #s_event_module_elements > > Thanks. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
