9888 2010-06-09 13:00:24 +0000 Constants are not accessible when they're needed for most IndexedDB interfaces. 2010-06-15 20:02:27 +0000 1 1 1 Unclassified WebAppsWG Indexed Database API unspecified PC All RESOLVED WORKSFORME P2 normal --- 1 jorlow nikunj.mehta mike public-webapps sdwilsh public-webapps-bugzilla oldest_to_newest 36063 0 jorlow 2010-06-09 13:00:24 +0000 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. 36184 1 nikunj.mehta 2010-06-15 14:33:14 +0000 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. 36185 2 nikunj.mehta 2010-06-15 14:39:14 +0000 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. 36186 3 nikunj.mehta 2010-06-15 14:58:44 +0000 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. 36188 4 jorlow 2010-06-15 15:01:04 +0000 (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? 36190 5 jorlow 2010-06-15 15:02:13 +0000 (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...? 36198 6 nikunj.mehta 2010-06-15 20:00:43 +0000 (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. 36201 7 nikunj.mehta 2010-06-15 20:02:27 +0000 The spec already does what the bug asks for. Check WebIDL for more help with access constants defined in interfaces.