OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


It wouldn't make a big difference for WebCGM, whether the event
listener is added to the Metafile or to the Picture interface.

However, if any profile lateron uses multiple pictures, then
it is an advantage to have it on the Metafile vs. one on each
picture.

I agree, let's not waste time with this now,  

Dieter

> -----Original Message-----
> From: Benoit Bezaire [mailto:benoit@itedo.com] 
> Sent: Wednesday, August 24, 2005 9:01 PM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: Re[3]: [cgmo-webcgm] ISSUE: should no-target-object 
> block event dispatch?
> 
> Wednesday, August 24, 2005, 10:00:28 AM, Lofton wrote:
> 
> LH> Thanks for the clarification, Benoit.
> No problem.
> 
> LH> One more question (or actually two more):
> 
> LH> Why did we move addEventListener to the Metafile interface?  Was 
> LH> that an attempt to take care of onload events, or was 
> there another motivation?
> I don't see how answering these questions improves the situation.
> (Honestly I don't quite remember exactly, but I think it's 
> beside the point).
> 
> LH> Is that now made moot by the 'onload' PARAM of the 
> 'object' element?
> I'm not sure, but the questions were about duplication of 
> bullets and events being dispatched to specific objects. I 
> gave my view on this; I don't think we should re-visit the 
> location of addEventListener (unless someone has an 
> implementation issue).
> 
> LH> Other implementors:  your feedback would be interesting.
> I agree with Lofton, it would be nice to hear from others.
> 
> -- 
>  Benoit   mailto:benoit@itedo.com
> 
>  
> LH> Thoughts?  What did you implement?  Etc.
> 
> LH> -Lofton.
> 
> LH> 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 
> >>LH> would be great if we had some examples in the text (as 
> resolved at 
> >>LH> July meeting), and some tests in the test suite (are there any 
> >>LH> yet?  or are they all
> >>still
> >>LH> open Action Items?).
> >>
> >>LH> Let me ask for some clarification, about the questions of "evt 
> >>LH> handler at 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 
> >>LH> listener
> >>with
> >>LH> a particular object (whether the object is an APS or a 
> Picture).  
> >>LH> The WebCGMEvent interface does contain a read-only attribute, 
> >>LH> '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 
> >>LH> from SVG (which I assume has the ability to associate handlers 
> >>LH> with objects, but don't have time to check now?), but did not 
> >>LH> implement that model in our 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 
> >>LH> the 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.
> 
> 
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]