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

[Dieter Weidenbrück <dieter@itedo.com>]

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

> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com] 
> Sent: Wednesday, August 24, 2005 3:11 PM
> To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
> Subject: RE: [cgmo-webcgm] ISSUE: should no-target-object 
> block event dispatch?
> 
> 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.
> > >
> > >
> > >
> 
> 
>