Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

On Thu, Feb 10, 2011 at 5:58 PM, Jeremy Orlow <jorlow@chromium.org> wrote:

> On Thu, Jan 27, 2011 at 5:14 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Wed, Jan 26, 2011 at 11:47 AM, Jeremy Orlow <jorlow@chromium.org>
>> wrote:
>> > What's the current thinking in terms of events that we're firing?  I
>> > remember we talked about this a bit, but I don't remember the conclusion
>> and
>> > I can't find it captured anywhere.
>> > Here's a brain dump of the requirements as I remember them:
>> > * Everything should have a source attribute.
>> > * Everything done in the context of a transaction should have a
>> transaction
>> > attribute.  (Probably even errors, which I believe is not the current
>> case.)
>> > * Only success events should have a result.
>> > * Only error events should have a code and a message....or should they
>> just
>> > have an error attribute which holds an IDBDatabaseError object?  (If
>> it's
>> > the former, then do we even need an interface for IDBDatabaseError to be
>> > defined?)
>> > * IIRC, Jonas suggested at some point that maybe there should be
>> additional
>> > attributes beyond just the source and/or objects should link to their
>> > parents.  (The latter probably makes the most sense, right?  If so, I'll
>> bug
>> > it.)
>> > Is there anything I'm missing?
>> > As far as I can tell, this means we need 5 events: an IDBEvent (with
>> source)
>> > and then error with transaction, error without, success with, and
>> success
>> > without.  That seems kind of ugly though.
>> > Another possibility is that we could put a transaction attribute on
>> IDBEvent
>> > that's null when there's no transaction.  And then error and success
>> would
>> > have their own subclasses.  To me, this sounds best.
>> > Thoughts?
>>
>> Actually, I was proposing something entirely different.
>>
>> IDBRequest should look like this:
>>
>> interface IDBRequest : EventTarget {
>>
>
> For each, what do we do when it's not available?  Throw exception?  Return
> undefined?  Null?  Particularly in the errorCode case, it's not clear to me
> what the right thing to do is.
>
>

How do IDBVersionChangeEvent and its version attribute fit in to this new
model?  Should we add a nullable version attribute to IDBRequest and let the
function handling a blocked event check event.target.version?  Could we add
a version attribute just to IDBVersionChangeRequest?

   attribute any result;
>>    attribute unsigned long errorCode;
>>    attribute DOMObject source;
>>    attribute IDBTransaction transaction;
>>
>
>>    const unsigned short LOADING = 1;
>>    const unsigned short DONE = 2;
>>    readonly attribute unsigned short readyState;
>>
>>             attribute Function       onsuccess;
>>             attribute Function       onerror;
>> };
>>
>> "success" and "error" events are plain Event objects, i.e. no
>> indexedDB-specific properties.
>>
>> The advantage of this is:
>> 1. Request objects are actually useful as representing the request.
>> Consumers of a request can check what the readystate is and either get
>> the .result or attach a event listener as appropriate. (As things
>> stand now you can't really rely on .readyState. The only thing it
>> tells you is if you got to the request too late or not. If you risk
>> getting there too late you better rewrite your code)
>> 2. Easier to implement a promises-style API on top of indexedDB.
>> 3. More similar to for example XMLHttpRequest
>>
>> The downside is:
>> 1. Have to use a bigger syntax to get to the result. "event.result"
>> vs. "event.target.result".
>>
>> / Jonas
>>
>
>