This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
WebIDL provides the ExceptionConsts modifier that can tie constants to an exception. Would this kind of a solution work for IndexedDB constants? For example: [ExceptionConsts=FileIOException] module fileio { exception FileIOException { unsigned short code; }; const unsigned short FILE_NOT_FOUND = 1; const unsigned short READ_ERROR = 2; const unsigned short WRITE_ERROR = 3; }; ECMAScript typeof FileIOException; // evaluates to "object" FileIOException.FILE_NOT_FOUND; // evaluates to 1 Now I just need to find out whether ExceptionConsts can be used with non-exception consts.
Looks like all I need to do is add [NoInterfaceObject] to KeyRange to solve this problem. If we find a similar issue with any other interface, it could be solved that way.
Actually upon closer inspection, I realize why I had removed the NoInterfaceObject modifiers from the spec, more or less completely. Per WebIDL, you should be able to access any constant from the interfaces just as intuitively understood. If not, check your IDL compiler. Once I get confirmation of this from the WebApps WG, I will close this issue as INVALID.
(In reply to comment #1) > WebIDL provides the ExceptionConsts modifier that can tie constants to an > exception. Would this kind of a solution work for IndexedDB constants? For > example: > > [ExceptionConsts=FileIOException] > module fileio { > > exception FileIOException { > unsigned short code; > }; > > const unsigned short FILE_NOT_FOUND = 1; > const unsigned short READ_ERROR = 2; > const unsigned short WRITE_ERROR = 3; > }; > > ECMAScript > > typeof FileIOException; // evaluates to "object" > FileIOException.FILE_NOT_FOUND; // evaluates to 1 > > Now I just need to find out whether ExceptionConsts can be used with > non-exception consts. It looks like this has been dropped in the latest editors draft: http://dev.w3.org/2006/webapi/WebIDL/#changes From a quick read, it seems as though implementing exceptions correctly in the spec should at least partially fix the problem though...and that the norm is to have an exception class that's closely tied to an error class which holds the constants. So I think you're on the right track, but it seems as though "ExceptionConsts" itself is not the right direction. I'd also note that, since IDBDatabaseError/Exception is not in the global namespace (right?) this wouldn't solve this bug...but implementing exceptions correctly (in terms of WebIDL) is (or should be) in some other bug. (In reply to comment #2) > Looks like all I need to do is add [NoInterfaceObject] to KeyRange to solve > this problem. If we find a similar issue with any other interface, it could be > solved that way. I'm looking at http://dev.w3.org/2006/webapi/WebIDL/#NoInterfaceObject but can't see how this solves the problem. Can you please explain further?
(In reply to comment #3) > Actually upon closer inspection, I realize why I had removed the > NoInterfaceObject modifiers from the spec, more or less completely. Per WebIDL, > you should be able to access any constant from the interfaces just as > intuitively understood. If not, check your IDL compiler. > > Once I get confirmation of this from the WebApps WG, I will close this issue as > INVALID. I.e. they should all be in the global namespace? Hm...typically we avoid stuff like this, but since everything has a IDB prefix maybe that's OK...?
(In reply to comment #5) > (In reply to comment #3) > > Actually upon closer inspection, I realize why I had removed the > > NoInterfaceObject modifiers from the spec, more or less completely. Per WebIDL, > > you should be able to access any constant from the interfaces just as > > intuitively understood. If not, check your IDL compiler. > > > > Once I get confirmation of this from the WebApps WG, I will close this issue as > > INVALID. > > I.e. they should all be in the global namespace? Hm...typically we avoid stuff > like this, but since everything has a IDB prefix maybe that's OK...? There will be a few interfaces in global scope for each of the interfaces with constants. That is how every spec seems to work.
The spec already does what the bug asks for. Check WebIDL for more help with access constants defined in interfaces.