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

[Lofton Henderson <lofton@rockynet.com>]

Thanks for the clarification, Benoit.

One more question (or actually two more):

Why did we move addEventListener to the Metafile interface?  Was that an 
attempt to take care of onload events, or was there another motivation?  Is 
that now made moot by the 'onload' PARAM of the 'object' element?

Other implementors:  your feedback would be interesting.  Thoughts?  What 
did you implement?  Etc.

-Lofton.

At 09:26 AM 8/24/2005 -0400, Benoit Bezaire wrote:
>Hi Lofton,
>
>See inline...
>
>Wednesday, August 24, 2005, 9:10:30 AM, Lofton wrote:
>
>LH> Dieter,
>
>LH> I'm on a bit of shaky ground with this event handler stuff.  It would be
>LH> great if we had some examples in the text (as resolved at July meeting),
>LH> and some tests in the test suite (are there any yet?  or are they all 
>still
>LH> open Action Items?).
>
>LH> Let me ask for some clarification, about the questions of "evt handler at
>LH> Picture level" or "target object has appropriate event handler"...
>
>LH> 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.
>
>LH> Indeed, addEventListener does not have any way to associate a listener 
>with
>LH> a particular object (whether the object is an APS or a Picture).  The
>LH> WebCGMEvent interface does contain a read-only attribute, 'target', 
>for use
>LH> by the event handler.  But it doesn't seem to me that is useful in
>LH> determining how to dispatch the event, correct?
>Correct. The read-only attribute 'target' is populated after the
>viewer determined which object was clicked on. In WebCGM 2, events are
>also dispatched (if they are dispatched) to the Metafile object, what
>changes from one dispatch to another is: the target, the event type
>and the position (x,y)).
>
>LH> It appears that we borrowed the description of event dispatching from SVG
>LH> (which I assume has the ability to associate handlers with objects, but
>LH> don't have time to check now?), but did not implement that model in our
>LH> interfaces.
>Correct.
>
>LH> Which did we intend, which do we want?  The model as described in 
>5.7.10 or
>LH> the model as implemented in our interfaces?
>
>LH> Your comments, Dieter, imply that our interfaces are correct and the
>LH> description in 5.7.10 is wrong.  Yes?
>Please see a previous email of mine describing the 3 bullets. That was
>my intention and that's what we implemented.
>
>Regards,
>
>--
>  Benoit   mailto:benoit@itedo.com
>
>LH> -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.
> >> >
> >> >
> >> >