[dojo-contributors] Dojo 1.9 Proposal

Ken Benjamin kenbenjamin at kenbenjamin.net
Wed Oct 17 11:31:27 EDT 2012

This sounds like a useful feature set. I know I’ve seen many requests on
the regular mailing list for something like this and the answer has always
been either rather too complex or “not possible” (usually to avoid getting
into exactly how complex it is for newbies).

I’m sure there will be many scenarios where devs want it to do something it
won’t do but that’s the case with the other Store modules now. That there
is an underlying framework to extend is of great value, as is the
consistent API.


Ken B

*From:* dojo-contributors-bounces at mail.dojotoolkit.org [mailto:
dojo-contributors-bounces at mail.dojotoolkit.org] *On Behalf Of *Kitson Kelly
*Sent:* Wednesday, October 17, 2012 3:59 PM
*To:* dojo dev.
*Subject:* Re: [dojo-contributors] Dojo 1.9 Proposal

Sorry if I am confusing people, but the two items Dylan stated were my
intention, however badly stated.  Though the mechanisms are not yet fully
fleshed out, though after some of the conversation here and further back of
the mind thinking, I see two clear points:

·  A consistent interface to persistent local storage that is dojo/store
compatible.  This transparently support IndexDB and Web Storage (and maybe
other forms of persistent local storage).  This could be accomplished in
a similar fashion to the way dojo/request works in detecting the
appropriate platform via the has API, which of course can be overridden by
a developer directly accessing the appropriate module.  This means in most
use cases an end developer just needs to require a single module (e.g.
"dojo/store/LocalStorage") and they are abstracted from the specifics of
the user agent and the specific API implementation.

·  A second module that is an "intelligent" cache that is a configurable,
cross store, transaction coordinator.  Again, abstracting the end developer
from the specifics of the implementation, it would handle applying
transactions across a set of stores, in memory, local and remote.

I would envision something like this:

require(["dojo/store/JsonRest", "dojo/store/LocalStorage",
"dojo/store/Memory", "dojo/store/Sync"],

function(JsonRest, LocalStorage, Memory, Sync){

  var jsonStore = new JsonRest({ target: "/items/" }),

      localStore = new LocalStorage({}),

      memoryStore = new Memory({});

  var store = new Sync([jsonStore, localStore, memoryStore], {});

  var item = store.get(12345);

  item.foo = "bar";




The appropriate events could be emitted on the Sync to deal with atomic
transactions, committing of the transactions across stores, handling of
offline behaviour, etc. though the most "generic" behaviour would occur so
that the end developer wouldn't have to be consciously aware of
the implementation.  I know that can open up the door for end developers
doing stupid things, like using persistent local storage improperly, but
that should prevent us from building on top of the raw power of the user
agent and serving it up in a consistent fashion.  With the above, I don't
have to know about IndexDB or Web Storage.  I have a simply, consistent
pattern that I can apply, which automagically works with by data aware
widgets and in most cases, deals with the "tough things" for me, but also
is open enough for me to "plug" into it to change the behaviour once I
realise I have an edge case that I need to deal with, or tune the


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121017/f8f64618/attachment-0001.htm 

More information about the dojo-contributors mailing list