W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

RE: [indexeddb] Updates to the Event Constructor to match DOM 4

From: Israel Hilerio <israelh@microsoft.com>
Date: Thu, 22 Sep 2011 00:52:31 +0000
To: "annevk@opera.com" <annevk@opera.com>, "Jonas Sicking (jonas@sicking.cc)" <jonas@sicking.cc>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D2706CF@TK5EX14MBXC119.redmond.corp.microsoft.com>
On Wednesday, September 21, 2011 2:50 PM, Jonas Sicking wrote:
> On Wed, Sep 21, 2011 at 11:58 AM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > Jonas,
> >
> > This is our interpretation of how we see incorporating the new Event
> constructor model defined in DOM 4.
> >
> > [Constructor(DOMString type, optional IDBVersionChangeEventInit
> > IDBVersionChangeEventInitDict)] interface IDBVersionChangeEvent :
> > Event {
> >     readonly attribute DOMString oldVersion;
> >     readonly attribute DOMString newVersion;
> >     void initIDBVersionChangeEvent (DOMString typeArg, boolean
> > canBubbleArg, boolean cancelableArg, DOMString oldVersion, DOMString
> > newVersion); };
> >
> > dictionary IDBVersionChangeEventInit : EventInit {
> >   DOMString oldVersion;
> >   DOMString newVersion;
> > }
> 
> Looks great apart from needing to remove the init function as Anne points
> out.
> 

Makes sense, I originally had it for interoperability but I see Anne's point.

[Constructor(DOMString type, optional IDBVersionChangeEventInit
IDBVersionChangeEventInitDict)] interface IDBVersionChangeEvent :
Event {
    readonly attribute DOMString oldVersion;
    readonly attribute DOMString newVersion;
};

dictionary IDBVersionChangeEventInit : EventInit {
   DOMString oldVersion;
   DOMString newVersion;
}

> > We'll need to add a step between 3 and 4 to section 4.12 and a note:
> > 3.5 After dispatching the event, if the event was not cancelled and allowed
> to bubble, then dispatch an ErrorEvent with the type set to "error" to the
> Window.
> 
> You don't need to state "and allowed to bubble", all events dispatched by
> this algorithm bubble as per step 3.
> 

I'll update the text to say:
3.5 After dispatching the event, if the event was not cancelled, then dispatch an ErrorEvent with the type set to "error" to the Window.

> > NOTE: When constructing an IDBVersionChangeEvent you need to follow
> the same steps defined in DOM4 Section 4.3 Constructing events.  In
> addition, setting the onerror event handler with window.addEventListener
> will return the ErrorEvent.  However, setting the onerror event handler with
> window.onerror will return three arguments as specified in HTML5 spec:
> event, source, and lineno [1].
> 
> I agree with Anne, this language is confusing. Dispatch of the onerror handler
> is handled by the HTML5 so I'm not sure we need to say anything here.
> 

Makes sense!

> > Sample code on how to use the event constructor:
> > var myDictionary = { canBubble: true, cancellable: true, oldVersion=1,
> > newVersion=2}; var changeEvent = new
> > IDBVersionChangeEvent("versionchange", myDictionary);
> 

Sounds good! The updated example will look like this:
var myDictionary = { bubbles: true, cancellable: true, oldVersion=1, newVersion=2}; 
var changeEvent = new IDBVersionChangeEvent("versionchange", myDictionary);

> Per [1] you should change 'canBubble' to 'bubbles'.
> 
> [1] http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#eventinit
> 
> / Jonas

Cool, I will work with Eliot to update the spec.

Israel
Received on Thursday, 22 September 2011 00:53:08 GMT

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