Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: storm.mark@gmail.com Newsgroups: comp.lang.javascript Subject: Re: Is this the only way to unit-test an events abstraction? Date: Wed, 21 Dec 2011 01:27:18 -0800 (PST) Organization: http://groups.google.com Lines: 104 Message-ID: <23062766.184.1324459638434.JavaMail.geo-discussion-forums@vbmi7> References: <6567149.685.1324401412063.JavaMail.geo-discussion-forums@yqbo42> <1658658.tIHn9WeWv6@PointedEars.de> Reply-To: comp.lang.javascript@googlegroups.com NNTP-Posting-Host: 82.71.25.212 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1324459755 3515 127.0.0.1 (21 Dec 2011 09:29:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 21 Dec 2011 09:29:15 +0000 (UTC) Cc: "Thomas 'PointedEars' Lahn" In-Reply-To: <1658658.tIHn9WeWv6@PointedEars.de> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.71.25.212; posting-account=T4f16goAAADn50g7_7A3mHd3PneLhXVB User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.javascript:9486 On Tuesday, 20 December 2011 21:02:23 UTC, Thomas 'PointedEars' Lah= n wrote: > Please put your real name there. Sorry about that, I had put my name at the bottom so people knew who they w= ere talking to. > So you should post the code that you are asking about,=20 > 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=20 > addEventListener(), attachEvent() and proprietary event-handler propertie= s=20 > would be semantically identical; they are not: I was aware of the differences (e.g. addEventListener includes capturing ph= ase and attachEvent only bubbling, global window object for attachEvent com= pared 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 atta= chEvent and fall back to proprietary event-handler is because of the lack o= f event execution order (in your fallback I believe you're storing up the l= istener functions and execute them in the relevant order and pass through a= normalised event object) =20 > Further, you should _not_ assume that because the object referred to by= =20 > `this' (the global object) exposes the method, all objects must expose it= ,=20 > and that it must be working for all event types. The same applies for th= e=20 > assumption of the opposite. The more reliable approach, if slightly less= =20 > efficient, is to use the approach that appears to be working when the eve= nt=20 > 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 ad= ding function, you suggest doing the check every time for whatever object t= he adding of an event is called on (even though it's slightly less efficien= t). > For an event-handling script that implements all of this and has (therefo= re?) survived bad storms (no pun intended), see=20 > Thanks for the link, I will be going over this thoroughly to make sure I un= derstand everything that's going on. > That is partially correct. `typeof' is an *operator*, it does not *retur= n*=20 > anything. "unknown" may be the *result* of a `typeof' operation in *all*= =20 > DOM implementations; there is no limit as to in which implementations it = may=20 > be the result, or up to which MSHTML version it can be returned. =20 > ActiveX/COM has little to do with it; the point is those are *host* objec= ts,=20 > and their `typeof' operation is allowed, by Specification, to result in a= ny=20 > string (loosely speaking). See ECMA-262 Ed. 3 and 5.1, sections 11.4.3, = for=20 > details. OK, thanks for clarifying the 'terminology' of return and result (looking a= t 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 obje= ct/method > [JFTR: I am partially responsible for the way David's isHostMethod() look= s=20 > today, for IIRC I have started this is=85Method() business with isMethod(= )=20 > years ago (search the archives). Curiously enough, I have recently=20 > (JSX@234) found it useful to "split" jsx.object.isMethod() so that there= =20 > would be jsx.object.isNativeMethod() as well, as David did before, to tel= l=20 > 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 revi= ew how that works > If you mean feature-tests at runtime: No. For you would need to create a= n=20 > event object as well, which firstly cannot be done everywhere, secondly= =20 > would only create an event of one of the numerous event types if it worke= d,=20 > and thirdly you would require feature detection for that as well. So tha= t=20 > can only reduce your chances of getting a useful event library (0.5=B3 = =3D=20 > 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