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

[Benoit Bezaire <benoit@itedo.com>]

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.
>> >
>> >
>> >