Agenda

• Adam Souzis's idea from last week
  • see: http://article.gmane.org/gmane.comp.web.dojo.devel/4257
  • getting rid of result.forEach() and most of the rest of dojo.data.Result
  • different ways to call store.find():
    • var array = store.find(someQuery); // make simple things simple -- sync case
    • store.find(someQuery, {sync:false, oncompleted:fooFunc, onnext:barFunc, onerror:iggyFunc}); // calls onnext(item) for each item
    • store.find(someQuery, {sync:false, oncompleted:myfunc, array:true}); // calls myfunc(array) after all items are ready
  • or, some naming alternatives:
    • store.find(someQuery, {onnext:bar});
    • store.find(someQuery, {oneach:bar}); // "oneach" instead of "onnext"
    • store.find(someQuery, {forEach:bar}); // "forEach" instead of "onnext"
    • store.find(someQuery, {onnext:bar, onlast:foo}); // "onlast" instead of "oncompleted"
  • and another possible parameter, if you want to pass a object that the callback methods will be called on:
    • store.find(someQuery, {sync:false, oncompleted:obj.fooFunc, onnext:obj.barFunc, onerror:obj.iggyFunc, context:obj});

• dojo.data.Read API
  1. how do we do "reference faulting" (or whatever the right term is) -- the situation where you have a giant data graph on the server, and you only have 10% loaded into data objects on the client, and when you ask a data object for some related object, it may just hand you back some other object that was already in memory, or it may initiate a request to the server to get the needed data?
  2. what does store.get(theHobbit, 'author') return?
     • an Identity
     • a reference (what's a reference?)
     • an item that is guarenteed to be available
     • an item that may or may not be available
     • a Deferred?
     • any of the above?
  3. semantics of isItem() more like isItemAvailable() (and, if so, rename it)?
     • should isItem(x) return true if x is an item Identity instead of an item?
     • should isItem(x) return true if x is an item that has been deleted? Prior to a save? After a save?
     • [adamsz: yes to all these]
     • [skinner: yes for deleted items. no if x is an item Identity, not an item. If isItem(x) returns true when x is an item Identity, that makes it impossible to use isItem() to figure out what a call to store.get() has just returned, and so you can't write GUI display code.]
     • [mitchell: How about isItem(any) for type-check, exists(item) for existence test?]

• dojo.data.Result API
  1. how do we want to handle GUIs that page or scroll through large result sets?
     • explicitly encourage data stores like the YahooStore example?
     • explicitly discourage or forbid that type of iteration?
     • other alternatives?
  2. what does inProgress() mean?
     • forEach() loop is in progress?
     • data is loading (query has been sent, forEach() not yet called)?
     • either of the above?
     • ~[adamsz: for clarity maybe instead we should have a state member;
       • i think we need: initial, receiving, completed, error
       • compare with:
       • xmlhttprequest.readyState: 0 uninitialized, 1 open, 2 sent, 3 receiving, 4 loaded,
       • deferred.fired: -1 initial, 0 success, 1 error
       • ]~
     • [skinner: Having a state property seems like a good idea. Should the state property convey info about (a) progress loading data from the server (initial, receiving, completed), or (b) progress iterating through the forEach loop (initial, looping, completed), or (c) some combination of both? What's the name of the state property, and do we want some sort of getState() accessor method]
     • [mitchell: State member is good, for determining resultset state between store (local or remote) and JS client]
  3. signature for oncompleted callback?
     • [adamsz: oncompleted(iterator)]
     • [skinner: oncompleted(). We might consider passing an iterator to the callback method that the caller sets with setOnLoopCompleted(callback). We should not pass an iterator to the callback method that the caller sets with setOnFindCompleted(callback), since that doesn't work well with the style of access that we might want to do in paging/scrolling implementations like the YahooStore. Offering a synchronous-iterator creates a new implementation requirement that dictates that all results will be in memory at once. Synchronous looping is a nice feature to have, but we shouldn't impose the the all-results-in-memory requirement every time a find() is complete, as would be required if we automatically pass an iterator in to the oncompleted callback -- we should only impose the the all-results-in-memory requirement if the calling code explicitly asks for synchronous looping by calling a asIterator() or asArray() method. If we do have a asIterator() or asArray() method, I have a strong preference for asArray() instead of asIterator(), because looping through an array is something that every JavaScript textbook covers, whereas the iterator syntax is dojo-specific and less obvious.]
     • [mitchell: onCompleted(). We may also want to consider whether it makes sense to use "well known" topics for store or data events. Eg., dojo:data/store/yahoo1/recieving or dojo:data/store/yahoo1/valueChanged]

• dojo.data.Write API
  1. save()
     • store.save({sync: false})?
     • store.save({sync: false, onComplete: callback});
     • always return a Deferred, or sometimes a boolean?
     • default to sync, not async?
     • [adamsz: save({sync:true}), always return Deferred (test result.fired for success) ]
  2. include methods add() and remove()
     • store.set(kermit, color, "green");
     • store.add(kermit, color, "blue");
     • store.add(kermit, color, "aqua", {at: 0});
     • store.add(kermit, color, "cyan", {after: "blue"});
     • store.remove(kermit, color, "green");
     • [adamsz: ok, but lets name them add/removeValue. And significance of order and whether duplicate values are allowed should be implementation dependent. also, clarify that removeValue removes all matching values if there are duplicates.]
     • [mitchell: +1, clarify that add with no optional 4th parm adds at end of value list, and at can be used for remove as well.]
  3. should isDirty() with no args returns whether the current transaction is dirty?
     • [adamsz: yes]
     • [skinner: Why not isDirty(store), as per the current documentation, rather than isDirty()? Or are you saying we should support isDirty() and isDirty(store), with different semantics?]
     • [mitchell: 0, could we move this to change-tracking interface?]
  4. should dojo.data.Write include (extend) dojo.data.Read?

• add new code (where?, minor code style stuff first?)
  1. check in RemoteStore?
  2. check in mockXmlHttpRequest?
  3. move dojo.data.csv.Result out of .csv, for re-use?
     • [adamsz: yes, rename to something like SynchronousResult]
     • [mitchell: yes, assuming it's in sync with latest api]

• wait to sign off on some APIs (Read/Result/Write) until after we have some lessons learned from trying initial implementations?
  • [mitchell: yes]

Resolutions

• (not yet)

Transcript

(not yet)