Re: Detecting support for event types

On Aug 18, 12:09 pm, Peter Michaux <petermich...@xxxxxxxxx> wrote:
On Aug 17, 6:13 pm, RobG <rg...@xxxxxxxxxxxx> wrote:

[snip]

I'm still working on the best way to organise them, I need to study
the W3C specs more. Perhaps I need to use hasFeature first, then
try..catch.

What does that gain over just using try-catch?

If it returns false, don't even bother with the W3C event model.

I'm still not clear about the difference between the event model and
the Events *module* - does hasFeature('Events', '2.0') just mean
support for interface Event, or does it mean all of the interfaces for
the event model (Event, DocumentEvent, EventListener, EventTarget) but
not the extra ones like UIEvents, MutationEvents, etc.?

Anyhow, I figured hasFeaure might circumvent using try..catch on
interfaces where the module itself isn't supported, e.g. there are 7
interfaces in MutationEvent, if hasFeature(‘MutationEvents’,’2.0’)
returns false, that's 7 try..catch calls that can be avoided. I
figure it's more likely browsers will pretend to support modules than
not, or only implement part of them. Testing will reveal.


The only issue with try-
catch is it may syntax error in old browsers.

Yes, Thomas has posted a solution that I'll file away if it's really
needed.


The idea is to have a pre-calculated list of supported
event interfaces and types, then allow calling them by:

sendEvent( elementId, eventType [, parameterObject])

where each event type has a default parameter object that can be
modified by passing an object with just the parameters that need to be
set to some other value.

This reads like prototype-based inheritance and I find it is rare to
actually find situations where prototype-based inheritance is so
appropriate.

No, I have an isSupported method so you'd call:

if (isSupported('UIEvents')) {


The pre-calculated list is kept in isSupported using a closure and is
used so that the feature test doesn't have to happen every time.


The event interface to use with createEvent is calculated from the
list of supported interfaces. If the appropriate interface isn't
supported, the event isn't dispatched.

The way my feature testing has evolved would mean this "failure" is
too late. If the DOM has been manipulated and then depends on this
dispatch being successful and the dispatch will fail then the DOM
never should have been manipulated in the first place. In other words,
a widget isn't initialized unless it can be fully functional.

It can use the same isSupported test.


All this started because I wanted to know a good way of detecting
support for touch events

Apple's documentation is disappointingly dependent on
navigator.userAgent parsing.

and expanded to be a more general way to send
any event into the DOM.

I've never had any need for production code to send and even to a DOM
element. Do you?

No, but although that isn't where I started it seems to be where I'm
headed. The goal is a feature test for touch events. One approach is
to attach an ontouchstart (or some other touch event) listener and
fire it using dispatchEvent it to see what happens - it seems very
crude but was a starting point. Along the way it occurred to me that
detecting support for the TouchEvent interface might be sufficient and
a little more elegant. Then I got a bit sidetracked into a more
general detection of event modules...


Sending events to DOM elements could be useful in a test library.
Selenium does this but the code specific to each browser is a little
scary (admittedly they are writing something difficult.)

I think I prefer the 'unobtrusive' approach - if it doesn't look like
it'll work, don't attempt it and fallback to simpler stuff.


It seems Mozilla has changed its position on dispatchEvent. I'm
pretty sure that in Firefox 2 when a click event was fired on a link
using dispatchEvent, it follow the link, but Firefox 3 doesn't (nor
does IE using fireEvent), Safari 3 does. I haven't got to testing
other browsers but I expect this will only work in fairly modern
versions.

Maybe I'll go back to my original plan and do this just for touch
events.

What does something like
document.implementation.hasFeature('TouchEvent', 1.0) return?

I don't know, Apple's documentation doesn't provide any hints on the
version number or whether it should work with hasFeature - '1.0' is as
good a guess as any, I'll try it later. :-)


--
Rob
.

Relevant Pages

  • kernel panic when running tcpdump
    ... # Firmware Drivers ... # Other IDE chipsets support ... most of these also require special kernel boot parameters ... # Userland interfaces ...
    (Linux-Kernel)
  • Re: Embedded RTOS - features poll
    ... management and filesystems support, for example. ... interfaces where industry-standard interfaces exist. ... API's more annoying than those that make no effort to "fit" ... you already use an RTOS)? ...
    (comp.arch.embedded)
  • Re: object system...
    ... MI); there are Interfaces, ... modifiable operators like this don't exist in most languages, ... about a sane multiple dispatch instead of the mess. ... probably be optimized via a hash table or similar...). ...
    (comp.object)
  • Re: Basic oder nicht?
    ... Der Compiler will irgendwann mal elementare Typen nutzen, ... man kann mit Interfaces wunderbar Module ... implementieren Eben weil der Dispatch nicht langsam ist. ...
    (de.org.ccc)
  • Re: Barack vs. Joe the Plumber
    ... the second amendment and snooping on Americans. ... I didn't write the Dispatch news report so I didn't just make up ... the Cuyahoga County Child Support Enforcement Agency and the ...
    (rec.sport.golf)