- From: Kris Zyp <kris@sitepen.com>
- Date: Tue, 25 May 2010 10:03:04 -0600
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/24/2010 2:10 PM, Jonas Sicking wrote: > On Fri, May 21, 2010 at 6:59 PM, Kris Zyp <kris@sitepen.com> wrote: >>> or to use something like >>> >>> put(record, {forbidOverwrite: true}); // don't overwrite >>> put(record, {onlyOverwrite: true}); // must overwrite/update >>> put(record, {}); or put(record); // can do either >>> >>> or some such. >>> >>> However ultimately I feel like this directive will be used often >>> enough that it makes sense to create explicit API for it. The >>> implementation overhead of separate functions is really not that >>> big, and I can't see any usage overhead? >> >> I am not too concerned about the implementation. But, as we been using >> this API in SSJS, we have been increasingly using a wrapper pattern, >> wrapping low-level stores with additional functionality that exposes >> the same API. Wrappers add functionality such as caching, data change >> notifications, extra validation, and so. The more methods that are >> exposed the more difficult it is wrap stores. > > Couldn't you always simply call addOrModify (or whatever we'll end up > calling it)? Given that neither localStorage or WebSQLDatabase > supports 'forbid overwrite' inserts it seems like this should work? > >> Don't assume that the API will only be consumed. > > Definitely. The API is definitely intended to be consumable by > libraries. In fact, I suspect that will be the case more often than > not. I'm not really sure that I'm following how the proposed API is > library un-friendly? > > / Jonas A quick example of what I mean by the wrapper pattern we have been using a lot: // A store wrapper that adds auto-assignment of attribution properties to a store function Attribution(store){ return { put: function(record, directives){ record.updatedBy = currentUser; record.updatedAt = new Date(); return store.put(record, directives); }, get: store.get.bind(store), delete: store.delete.bind(store), openCursor: store.openCursor.bind(store), }; } Obviously if there are three methods it makes every wrapper more complicated. If we were to move to three methods, could we at least call them add/modify/put? Keeping the get, put, delete methods with REST correspondence is extremely nice property of the API (both in terms of consistency with familiar terms and ease of use in RESTful systems). - -- Kris Zyp SitePen (503) 806-1841 http://sitepen.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv79LcACgkQ9VpNnHc4zAwTpwCfaYoaDRu07REGTTPgmC6SBQec pr0An0RmyQBmOchw5m1coz6h4Pf4Mtju =1OuE -----END PGP SIGNATURE-----
Received on Tuesday, 25 May 2010 16:03:49 UTC