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

Re: [IndexedDB] Events and requests

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 10 Nov 2010 11:23:41 -0800
Message-ID: <AANLkTikq7Oe7VULaVptEYpjsv1w+Pb-4YeeL1T-e2inj@mail.gmail.com>
To: Shawn Wilsher <sdwilsh@mozilla.com>
Cc: Webapps WG <public-webapps@w3.org>
On Wed, Nov 10, 2010 at 10:38 AM, Shawn Wilsher <sdwilsh@mozilla.com> wrote:
> 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.

Cool.

>> 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).

Yes, that's the only difference.

/ Jonas
Received on Wednesday, 10 November 2010 19:24:35 GMT

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