W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [IndexedDB] Events and requests

From: Shawn Wilsher <sdwilsh@mozilla.com>
Date: Wed, 10 Nov 2010 10:38:50 -0800
Message-ID: <4CDAE6BA.10304@mozilla.com>
To: Jonas Sicking <jonas@sicking.cc>
CC: Webapps WG <public-webapps@w3.org>
On 11/9/2010 12:35 AM, Jonas Sicking wrote:
> 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).
This seems fine to me.

> 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);
> }
The only difference is e.result vs e.target.result, right?  I'm not sure 
we should worry about that little bit (and consumers can always use a 
local variable for that if it bothers them).

Cheers,

Shawn



Received on Wednesday, 10 November 2010 18:39:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:41 GMT