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

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.


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