Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #9486

Re: Is this the only way to unit-test an events abstraction?

Show all headers | View raw

On Tuesday, 20 December 2011 21:02:23 UTC, Thomas 'PointedEars' Lahn  wrote:

> Please put your real name there.
Sorry about that, I had put my name at the bottom so people knew who they were talking to.

> So you should post the code that you are asking about, 
> not just a URL to some Web site (even if it is a code repository).
Understood. Will do in future.

> That said, your approach is based on the common misconception that 
> addEventListener(), attachEvent() and proprietary event-handler properties 
> would be semantically identical; they are not:
I was aware of the differences (e.g. addEventListener includes capturing phase and attachEvent only bubbling, global window object for attachEvent compared to event object for addEventListener, only a single event allowed for proprietary event-handlers).

That being said there were a couple of things I wasn't aware of though: the order of events with attachEvents not being guaranteed & 'this' refers to the same object as 'window',  _not_ to the object that handled the event.

> Bottom line: Eschew attachEvent().
So the reason why (in your provided example script) you do not utilise attachEvent and fall back to proprietary event-handler is because of the lack of event execution order (in your fallback I believe you're storing up the listener functions and execute them in the relevant order and pass through a normalised event object)
 
> Further, you should _not_ assume that because the object referred to by 
> `this' (the global object) exposes the method, all objects must expose it, 
> and that it must be working for all event types.  The same applies for the 
> assumption of the opposite.  The more reliable approach, if slightly less 
> efficient, is to use the approach that appears to be working when the event 
> was created.
So (as I can see in your example code) instead of doing what I am, which is to check for addEventListener on the window object and then rewrite the adding function, you suggest doing the check every time for whatever object the adding of an event is called on (even though it's slightly less efficient).

> For an event-handling script that implements all of this and has (therefore?) survived bad storms (no pun intended), see 
> <http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk%2Fdom%2Fevents.js>
Thanks for the link, I will be going over this thoroughly to make sure I understand everything that's going on.

> That is partially correct.  `typeof' is an *operator*, it does not *return* 
> anything.  "unknown" may be the *result* of a `typeof' operation in *all* 
> DOM implementations; there is no limit as to in which implementations it may 
> be the result, or up to which MSHTML version it can be returned.  
> ActiveX/COM has little to do with it; the point is those are *host* objects, 
> and their `typeof' operation is allowed, by Specification, to result in any 
> string (loosely speaking).  See ECMA-262 Ed. 3 and 5.1, sections 11.4.3, for 
> details.
OK, thanks for clarifying the 'terminology' of return and result (looking at it now I can see how my wording is confusing).
I'll also be wary of relying on 'unknown' as a way of detecting a host object/method

> [JFTR: I am partially responsible for the way David's isHostMethod() looks 
> today, for IIRC I have started this is…Method() business with isMethod() 
> years ago (search the archives).  Curiously enough, I have recently 
> (JSX@234) found it useful to "split" jsx.object.isMethod() so that there 
> would be jsx.object.isNativeMethod() as well, as David did before, to tell 
> user-defined event listeners from unsuitable objects apart in event.js.]
I'll search the archives here to see if I can locate your isMethod and review how that works

> If you mean feature-tests at runtime: No.  For you would need to create an 
> event object as well, which firstly cannot be done everywhere, secondly 
> would only create an event of one of the numerous event types if it worked, 
> and thirdly you would require feature detection for that as well.  So that 
> can only reduce your chances of getting a useful event library (0.5³ = 
> 0.125).
I'll review your provided script and see how you've gone about implementing your events library then so I make sure I'm understanding all the concepts correctly.

Mark

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Is this the only way to unit-test an events abstraction? storm.mark@gmail.com - 2011-12-20 09:16 -0800
  Re: Is this the only way to unit-test an events abstraction? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-20 22:02 +0100
    Re: Is this the only way to unit-test an events abstraction? storm.mark@gmail.com - 2011-12-21 01:27 -0800
      Re: Is this the only way to unit-test an events abstraction? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-21 13:42 +0100
    Re: Is this the only way to unit-test an events abstraction? John G Harris <john@nospam.demon.co.uk> - 2011-12-21 17:25 +0000
      Re: Is this the only way to unit-test an events abstraction? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-12-21 20:30 +0100
        Re: Is this the only way to unit-test an events abstraction? John G Harris <john@nospam.demon.co.uk> - 2011-12-22 15:22 +0000

csiph-web