[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 that an LH> 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 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]