Hi Michael,
Thanks for your reply. I will study more on the project within next week
and come up with both my issues and ideas. Since I was having my exams, I
could not focus much on the project and will be free after few more days. I
hope the support of you all to step forward.
Thanks.
On Mon, Mar 14, 2011 at 11:13 PM, Michael Glavassevich
<[email protected]>wrote:
> Hi Thiwanka,
>
> Thiwanka Somasiri <[email protected]> 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: [email protected]
> E-mail: [email protected]
>
>
--
Regards
A.S.Thiwanka Somasiri
Skype : executionerwild
MSN : [email protected]
<[email protected]>
