REST with dojo and PHP: Notes on using dgrid with a caching store

18 Replies

I would like to share some (personal) pitfalls I came across when creating the demo REST with dojo and PHP: Demo of a dgrid observing changes to the JsonRest store:

  • dojo/store/Observable only works correctly when the object has an id. Unfortunately, dojo/store/Memory.add(object) does not add the id to the object when creating it (as of 1.7.1) .¬† See bugs #12835 and #14281. For a fix see changeset #27072
  • Observable does only work correctly with a store, that provides a queryEngine. dojo/store/JsonRest does not have a queryEngine by default, so you will have to provide your own. If you are using a cache, observe the dojo/store/Memory directly. Upate 29.06.2012: For a fix see changeset¬†#29069.
  • As stated in the docs, but easily missed: dojo/store/Cache automatically adds all returned objects from get() and query() calls to the cache, but only get() uses the cache, whereas query() directly uses the master store. If you want the query to come from the cache, directly call query() on the caching store, e.g. dojo/store/Memory.
  • In the demo, the PHP script responds to the GET 2 by returning a Json object with id 2 and to a GET 2/ by returning an array of objects with parent id 2. If you want to query the Memory store for 2’s children, you have to provide an object as an argument, e.g. storeMemory.query({parId: 2}), whereas the JsonRest store expects a string e.g. storeJsonRest.query(‘2/’);
  • JsonRest store’s methods do not return the same types as Memory store, which can be confusing…
    storeMemory.add(newObject) returns the id
    storeJsonRest.add(newObject) returns the response from the server (or rather a Deferred providing it)
    …, but makes sense, because it can save an extra round trip to the server.

Also see dojo/store/Observable and dojo/store/Cache more info.