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

On Mon, Feb 14, 2011 at 7:36 PM, David Grogan <dgrogan@chromium.org> wrote:

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

Adding a "newVersion", "nextVersion", or something similar to
IDBVersionChangeRequest seems like the best answer to me.  Simply adding
"version" to it seems kind of confusing though.

J


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