RE: [cgmo-webcgm] ISSUE: should no-target-object block event dispatch?

[Lofton Henderson <lofton@rockynet.com>]

Dieter,

I'm on a bit of shaky ground with this event handler stuff.  It would be 
great if we had some examples in the text (as resolved at July meeting), 
and some tests in the test suite (are there any yet?  or are they all still 
open Action Items?).

Let me ask for some clarification, about the questions of "evt handler at 
Picture level" or "target object has appropriate event handler"...

At 10:36 AM 8/24/2005 +0200, Dieter  Weidenbrück wrote:
>[...]
> > >* Otherwise, there is a target object. If there is an event
> > handler at
> > >the Picture level with event capturing for the given event, then the
> > >event is dispatched to the Picture.
>There can't be an event handler at the Picture level, because the
>addEventListener funtion is on the metafile interface.
>Suggestion: change to reflect this.
>
> > >* Otherwise, if the target object has an appropriate event
> > handler for
> > >the given event, the event is dispatched to the target object.
>There is no way to add an event listener to an individual object,
>so this needs to be removed.

Indeed, addEventListener does not have any way to associate a listener with 
a particular object (whether the object is an APS or a Picture).  The 
WebCGMEvent interface does contain a read-only attribute, 'target', for use 
by the event handler.  But it doesn't seem to me that is useful in 
determining how to dispatch the event, correct?

It appears that we borrowed the description of event dispatching from SVG 
(which I assume has the ability to associate handlers with objects, but 
don't have time to check now?), but did not implement that model in our 
interfaces.

Which did we intend, which do we want?  The model as described in 5.7.10 or 
the model as implemented in our interfaces?

Your comments, Dieter, imply that our interfaces are correct and the 
description in 5.7.10 is wrong.  Yes?

-Lofton.



> > >* Otherwise, the Picture is checked to see if it has an appropriate
> > >event handler. The event is dispatched to the Picture if one
> > is found.
>Again, change Picture to Metafile.
>However, this doesn't make sense, as Lofton pointed out.
>
> > >* Otherwise, the event is discarded.
>No. We still have internal link handling, i.e. linking by linkURI
>attributes found in the file.
>
>
>Regards,
>Dieter
>
>
> >
> > (Long story short ... draw a flowchart of the above, with
> > four Y/N decision branches ... something is wrong.  In words,
> > the long story is...)
> >
> > I don't understand how the 2nd sentence of 2nd bullet relates
> > to the 4th bullet.  If there is an appropriate event handler
> > at the Picture level, how would the event-dispatch algorithm
> > ever get past the 2nd bullet?  2nd bullet says that eligible
> > Picture gets the event before eligible target object
> > (eligible = has handler), while 4th says eligible picture gets it
> > *after* eligible target object.  I would think that we mean
> > the 4th, right?  I.e., most specific wins?  I.e., closest to
> > leaf wins?
> >
> > I'm unclear why the dispatch-to-Picture (if eligible) of the
> > 2nd bullet should be contingent upon there being a target
> > object.  It basically
> > says:  if you click on a blank area of the picture, the event
> > is not dispatched (so Picture could not receive the event).
> > Is that what we intended?
> >
> > (Btw, the first bullet is effectively the same as SVG1.1.
> > SVG is now debating whether to change it, even at the expense
> > of being non-backward compatible[!], so that the containing
> > SVG element [i.e., our "Picture"] gets a chance at the event
> > if there is no target object.)
> >
> > Thoughts?
> >
> > Regards,
> > -Lofton.
> >
> >
> >