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

I am really sorry to bring this up again, but: Why not separate concerns? Why not separate input data and output data?

If onsuccess and onerror were handed in as an input parameters, would there be any need for readyState, LOADING, and DONE? Then IDBRequest would be more like an event, right? It would be sent to the onsuccess and onerror event handlers.

> Actually, I was proposing something entirely different.
> 
> IDBRequest should look like this:
> 
> interface IDBRequest : EventTarget {
>    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
> 
> 

-- 
Dr. Axel Rauschmayer
axel@rauschma.de
Home: http://rauschma.de
Blog: http://2ality.com

Received on Friday, 28 January 2011 01:30:59 UTC