temporal API and feature testing cascade
Peter Michaux
tests cannot be preformed during the script's initial evaluation
because the document.body must be available for the test. Configuring
a scroll reporting function is an example.
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdScroll
Another example is determining CSS support by adding test elements to
a page which is best left until after the page has finished loading
completely.
----
A primary goal of Fork is to provide developers an API which can be
used in the cascade of feature tests from library through application
level. A Fork function should only be defined if it is known to be
able to work in the particular browser. This way a developer's
application level can just check if the Fork function is present. This
gives a black-box abstraction of whatever host features upon which the
Fork function depends.
----
Given a Fork function should only be defined if it will work, and that
scroll reporting, for example, cannot be determined to work until the
document.body is available, it has lead in the direction of a
"temperal API". That is, Fork features may appear and possibly
disappear as time passes. Features are only available when they are
known to work.
I've never encountered a temperal API before but can think of places
in the browser scripting world where it would be useful. For example,
trying to attach a window onload event after the onload event has
fired could throw an error. The document.write property could just
disappear when it is not possible to call it. The DOM manipulation
functions could appear after the onload event.
----
The API to determine if a Fork feature is available must be simple. My
idea is to change the global "FORK" object from being just an Object
object to a Function object. A call to the FORK object with a feature
name will return that feature if it is available. For example, if a
developer is writing a drag drop widget, he will likely need to know
if Fork's getEventPageX is available. (This can only be determined to
be available if Fork's getPageScrollX is also available which cannot
be known until document.body is available.) The application code would
look like this
if (typeof FORK == 'function' &&
FORK('getEventPageX')) {
// do stuff with FORK.getEventPageX
}
Before document.body is available the FORK('getEventPageX') will
return undefined. After document.body is available the call will test
if the necessary browser features are available to define the
getEventPageX. If so then it will create the function and add it as a
property FORK.getEventPageX and also return that function. If the
browser cannot support that function then undefined is always
returned.
I think this syntax is both compact and has good similarity to the
built-in property accessor syntax
FORK('getEventPageX')
FORK['getEventPageX']
FORK.getEventPageX
JavaScript's bracket and dot notation are not powerful enough for the
requirements here. The use of a function call makes the FORK function
a dispatch function. This allows FORK to work like a "catch-all" as
JavaScript itself doesn't have catch-alls (at least not until
ECMAScript 4).
Any thoughts?
Peter
Declan
if (FORK && FORK.has("getEventPageX"))
What would be nice as well in my opinion is that if FORK is not
defined, that it is replaced by false. Then if (FORK) would be very
safe to use. I've only glanced through your new code (and spotted a
few possible errors along the way) but I think that's possible the way
you have it set up now.
Peter Michaux
>
> It's a nice idea, but I think I'd prefer something like
> if (FORK && FORK.has("getEventPageX"))
If FORK is undeclared (e.g. the file containing the declaration of
FORK failed to load) then the first part of the conditional above will
throw an error.
If FORK was just an Object object, then with the "has" property you
would need to write
if ((typeof FORK == 'object') &&
FORK && // ensure not null as null has typeof "object"
(typeof FORK.has == 'function) &&
FORK.has("getEventPageX"))
That is getting quite bulky, especially since it will be common for
every widget. That is the reason I arrived at having just
if ((typeof FORK == 'function') &&
FORK('getEventPageX'))
> What would be nice as well in my opinion is that if FORK is not
> defined, that it is replaced by false.
If the file declaring FORK does not load then there would be no way to
set it to false unless every file had code to do that at the top. I
think that would defeat any savings.
> Then if (FORK) would be very
> safe to use. I've only glanced through your new code (and spotted a
> few possible errors along the way) but I think that's possible the way
> you have it set up now.
The current code hasn't even been loaded into a JavaScript
interpreter. I've been trying to work out all the details I can by
thinking about the feature detection use. If you have seen any
conceptual problems in the current code please post about it.
I'm going to start using the new code a little bit soon and see how it fairs.
Peter
Peter Michaux
> if (FORK && FORK.has("getEventPageX"))
Why the preference for having the "has" property rather than just
using "FORK" as a function?
Peter