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[2]: [cgmo-webcgm] more questions about onload


Hi Lofton,

Please see inline...

Thursday, December 15, 2005, 3:30:00 PM, you wrote:

> At 04:39 PM 12/14/2005 -0500, Benoit Bezaire wrote:
>>Hi all,
>>
>>   So we've agreed that we want the 'onload' event to be dispatched
>>   every time 'src' changes. Ok.
>>
>>   Here's another question that has been bothering me lately... Assume
>>   we have the following js code:
>>
>>   var metafile = document.getWebCGMMetafile();
>>   metafile.src = 'myCGM.cgm';
>>   metafile.addEventListener("onload", myLoadFunction);
>>   metafile.src = 'myCGM2.cgm';

> Note, per my last email, that the name of the event in 5.7.10 is 'load',
> not 'onload'.
Yes, the event name is 'load', but is the event listener called 'load'
or 'onload'? I guess the spec should be clear about that.

>>   The current spec wording says that event listeners are added to the
>>   WebCGMMetafile object, but 'src' is loading a new metafile;
>>   shouldn't the event listener 'myLoadFunction' be discarded when
>>   'src' is modified?

> Hmmm... interesting question.

> The getWebCGMDocument() method on the WebCGM metafile interface says:  "If
> no WebCGM document is open in the viewer, the WebCGMMetafile object will
> still be returned."  I.e., we said once upon a time that "the metafile
> object always exists, even if no WebCGM has yet been defined."  Which 
> enables the case that there is no 'data' attribute on <object>, then 
> execution of the script:
Right.

>>   var metafile = document.getWebCGMMetafile();
>>   metafile.src = 'myCGM.cgm';

> An 'onload' <param> definition in the <object> element certainly persists
> across the "metafile.src = ..." statement, right?
Well we have to make clear, it's the purpose of this thread. Right
now, it is unspecified in my opinion.

> Why wouldn't the 'load' (onload) event listener definition that is
> made via "addEventListener("load", myLoadFunction)" persist in
> similar fashion? 
Because an implementation could attach the event listener to it's
'in-memory' metafile object... wish would imply that if .src is
modified and the 'in-memory' metafile object is deleted, the event
listener is discarded.

> Conclusion.  It seems to me that we want the definition of the 'load' 
> (onload) event listener to persist across definition or redefinition
> of the metafile ('src' attribute), don't we?
Dieter thinks so. I don't have an opinion.

> If that is all correct, what we seem to have come around to is this:

> 1.) for the case that the WebCGM metafile instance is defined on the 'data'
> attribute of the <object>, then you must use the 'onload' <param> if you
> want to catch the onload event.

> 2.) If you omit the 'data' attribute of the <object>, and define the 
> metafile via the .src attribute in script, then you may use the 
> addEventListener("load", ...) before setting the .src attribute.
If the event listener does persist, then yes, 1 & 2 is correct.

>>[...]
>>   Do we want to have the event listeners attached to the user agent or
>>   to the metafile? If it's to the user agent, then the
>>   'addEventListener' spec description needs to change.

> I'm not sure how to answer that question.  When we say "metafile", do we
> mean a particular WebCGM instance, or a metafile object (which apparently
> can exist without having a particular WebCGM instance attached.)
I meant a particular WebCGM instance.

> The above line of reasoning implies that you need to be able to
> attach the event listener to the metafile object, even when a
> particular WebCGM instance has not yet been associated with it.  (Am
> I making any sense, or is this all nonsense?)
Yes, but in my opinion those above lines that you pointed out are
unclear. They need to be improve.

So both you and Dieter are in favor of having the event listener
persist. What do others think?

-- 
 Benoit   mailto:benoit@itedo.com

> -Lofton.








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