- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 31 May 2011 15:40:37 -0700
- To: Jonas Sicking <jonas@sicking.cc>, Israel Hilerio <israelh@microsoft.com>, public-webapps@w3.org
On Tue, May 31, 2011 at 3:09 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Jonas Sicking:
>> At least in the indexedDB case we need to enumerate the object anyway
>> since we want to throw if it contains any properties that we don't
>> understand. This is for forwards compatible reasons.
>>
>> Hence we automatically limit ourselves to enumerable properties, so
>> toString wouldn't be a problem.
>
> The way I’ve specified dictionaries, there is no way to know what other
> properties might exist on the JS object. If you defined
>
> dictionary ObjectStoreCreationOptions {
> DOMString keyPath = "";
> boolean autoIncrement = false;
> };
>
> then the (IDL level) dictionary value will only ever have a keyPath and
> an autoIncrement entry.
>
> I could add a flag to the dictionary that indicates whether “unexpected”
> properties were on the (language level) object, so that IndexedDB can
> act upon it by throwing an exception. I’m just not sure that this is a
> common usage pattern of options objects in JS. To me, the simplest use
> of the properties on the options object would be:
>
> function createObjectStore(name, optionalParameters) {
> optionalParameters = optionalParameters || { };
> var keyPath = optionalParameters.keyPath || "";
> var autoIncrement = optionalParameters.autoIncrement;
> ...
> }
>
> Doing:
>
> function createObjectStore(name, optionalParameters) {
> optionalParameters = optionalParameters || { };
> var keyPath = optionalParameters.keyPath || "";
> var autoIncrement = optionalParameters.autoIncrement;
> for (var key in optionalParameters) {
> if (key != "keyPath" && key != "autoIncrement") {
> throw ...;
> }
> }
> ...
> }
>
> feels kind of unnecessary.
It's certainly harder to implement, but it does IMHO result in a
better API for webpages to use which is more important.
> Are you thinking that authors will feature
> test for new options by doing something like the following?
>
> try {
> createObjectStore("test", { newOption: 123 });
> } catch (e) {
> if (e.code == IDBDatabaseException.NON_TRANSIENT_ERR) {
> // fall back to something else that does use newOption
> }
> }
Yes, that is one option. Another could be something like:
if (objectStore.spiffyNewIndexes) {
objectStore.createIndex("test", { spiffy: true });
}
else {
objectStore.createIndex("test", { keyPath: "foo" });
}
In any case it's better to throw than silently ignore unknown properties IMHO.
/ Jonas
Received on Tuesday, 31 May 2011 22:41:34 UTC