[IndexedDB] Events and requests

Hi All,

One of the things we briefly discussed at the summit was that we
should make IDBErrorEvents have a .transaction. This since we are
allowing you to place new requests from within error handlers, but we
currently provide no way to get from an error handler to any useful
objects. Instead developers will have to use closures to get to the
transaction or other object stores.

Another thing that is somewhat strange is that we only make the result
available through the success event. There is no way after that to get
it from the request. So instead we use special event interfaces with
supply access to source, transaction and result.

Compare this to how XMLHttpRequests work. Here the result and error
code is available on the request object itself. The 'load' event,
which is equivalent to our 'success' event didn't supply any
information until we recently added progress event support. But still
it only supplies information about the progress, not the actual value
itself.

One thing we could do is to move

.source
.transaction
.result
.error

to IDBRequest. Then make "success" and "error" events be simple events
which only implement the Event interface. I.e. we could get rid of the
IDBEvent, IDBSuccessEvent, IDBTransactionEvent and IDBErrorEvent
interfaces.

We'd still have to keep IDBVersionChangeEvent, but it can inherit
Event directly.

The request created from IDBFactory.open would return a IDBRequest
where .transaction and .source is null. We already fire a IDBEvent
where .source is null (actually, the spec currently doesn't define
what the source should be I see now).


The only major downside with this setup that I can see is that the
current syntax:

db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess = function(e) {
  alert(e.result);
}

would turn into the slightly more verbose

db.transaction(["foo"]).objectStore("foo").get(mykey).onsuccess = function(e) {
  alert(e.target.result);
}

(And note that with the error handling that we have discussed, the
above code snippets are actually plausible (apart from the alert() of
course)).

The upside that I can see is that we behave more like XMLHttpRequest.
It seems that people currently follow a coding pattern where they
place a request and at some later point hand the request to another
piece of code. At that point the code can either get the result from
the .result property, or install a onload handler and wait for the
result if it isn't yet available.

However I only have anecdotal evidence that this is a common coding
pattern, so not much to go on.

/ Jonas

Received on Tuesday, 9 November 2010 08:36:04 UTC