On Tue, Aug 24, 2010 at 7:34 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Tue, Aug 24, 2010 at 10:30 AM, Jeremy Orlow <jor...@chromium.org> > wrote: > > Last we spoke about constants in IndexedDB, (like IDBKeyRange.LEFT_BOUND) > I > > believe we had decided that all the objects with constants would have an > > interface object hanging off of window so it's possible to simply say > > "IDBKeyRange.LEFT_BOUND" within JavaScript. What happens when someone > tries > > something like the following JS: |IDBCursor.continue()|? Given that > we're > > using an interface object, I'd assume we throw some sort of exception or > > something? I tried to figure out the answer in the WebIDL spec (I > imagine > > it's somewhere around > > here http://dev.w3.org/2006/webapi/WebIDL/#dfn-interface-object) but > it's a > > lot to wade through. Any advice would be great. > > I definitely think we should handle this the same way that all other > interfaces does it. I.e. the same way that > window.Node.appendChild(...) does it. In the Firefox implementation we > just fall back to using our generic code for all this stuff, so > nothing special goes on in the IndexedDB implementation. > > And yes, I think WebIDL should be the one defining what should happen. > If it doesn't already someone should file a bug :) > Ok, I figured out how interface objects are done in WebKit and got it implemented. And everything looks like it's working fine except for IDBKeyRange. The problem is that IDBKeyRange has 4 factory methods attached to it, but these aren't accessible from the interface object (and these factories are the only possible way to get such an object). It makes sense that methods are by default not considered static (i.e. must be called on an instance of the interface). But is there any way to override this behavior or can anyone point to other examples where this is done? Of course another option is to move the factory methods to IDBFactory (as was suggested earlier). This would just work since window.indexedDB() returns an IDBFactory object. If no one has any bright ideas about how to otherwise spec what's there, I'd suggest we make that change. I tried to figure all of this out on my own by reading the WebIDL spec, but I've found it almost impossible to digest. :-( > > Also, the spec still has "[NoInterfaceObject]" for a lot of the > interfaces. > > I believe Nikunj did this by accident and was supposed to revert, but I > > guess he didn't? I should file a bug to get these removed, right? > > Please do. > Done. > > Another question: Right now all the error constants are on > > IDBDatabaseException which is an exception rather than an interface. Is > > this allowed? And even if so, should we put them on IDBDatabaseError > > instead, given that it's the class people will be using more often (with > the > > async interface)? Or maybe we should duplicate the constants in both > > places? It just feels weird to me that I keep reaching into > > IDBDatabaseException for these constants. > > Exception stuff has always confused me, but I think this is how idl > elsewhere does it. > Ok, I guess we'll leave it then. J
