[Bug 9888] New: Constants are not accessible when they're needed for most IndexedDB interfaces.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9888

           Summary: Constants are not accessible when they're needed for
                    most IndexedDB interfaces.
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: nikunj.mehta@oracle.com
        ReportedBy: jorlow@chromium.org
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


In indexedDB, there are many cases where it's impossible to access a constant. 
For example, if I'm trying to create a key range, I might want to pass in
KeyRange.LEFT_OPEN.  Unfortunately, the only way to get at LEFT_OPEN is to
create a KeyRange.  This is true of pretty much all the objects and their
constants.

Another example is that you can't access the error constants without causing an
exception so you can get an IDBDatabaseException object.  But that's not even
possible outside of workers.

We could create global constructors, but it doesn't seem worth it to pollute
the namespace.  We could pull all the constants up one level.  For example, the
constants for Cursors would be added to IDBIndexes and IDBObjectstores since
those are both the places where you'd create a cursor.  If we wanted to avoid
the duplication, we could even pull all the constants up to the
IndexedDatabaseRequest level (where mozilla's proposal suggests we put the
keyRange constructors).

Until this is fixed, people using IndexedDB will need to use pretty ugly hacks
to get at the constants or hard code in the numbers themselves.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Wednesday, 9 June 2010 13:00:26 UTC