[dojo-contributors] Dojo data discussion

Brian Douglas Skinner skinner at dojotoolkit.org
Tue Jun 5 03:48:02 EDT 2007


Hey Jared,

Thanks for putting together the agenda.

> Agenda: 
> http://www.dojotoolkit.org/book/developers-notebook/data-access-meetings/data-access-meeting-2007-06-05 
> 
> Note:  Agenda is in the process of being filled out.  If you 
> have any items you wanted added to the agenda, please mail me 
> and I will add it.

I've got a couple additional things we could talk about if we have time. 
  I've been working on a read/write datastore that extends JsonItemStore 
to implement the Write and Notify interfaces.  I've run into a couple 
questions about the Write API...

(1) If I get the read/write JsonItemStore extension working, should that 
go in dojox.data or in dojo.data?  My first assumption was dojox, but it 
feels weird to have a subclass with dependencies on private variables in 
a class that's in an entirely different package.  Also, any suggestions 
for the name of the read/write JsonItemStore?

(2) What interaction do we want between newItem(), deleteItem(), 
isItem(), and save()?  If somebody does 
"store.isItem(store.newItem());", should that return true even though 
the new item hasn't been saved yet?  And if they do 
"store.deleteItem(foo); store.isItem(foo);", should isItem return false 
because because foo is no longer a valid item handle?  If not, then what 
about "store.deleteItem(foo); store.save(); store.isItem(foo);"?

(3) Our save() method is async, so the save may not happen right away. 
Is it legal to for the UI code to keep working with the datastore during 
the time between when an initial save({onComplete:callback}) call is 
started and when the completion callback is called?  Can the user create 
and delete items during that time, and if so, will those changes be 
buffered up and associated with the second save call rather than the 
first?  If the save operations take some time, and the callbacks don't 
get called for awhile, then you could potentially end up with several 
different save operations that are in progress at once -- do we want to 
allow that?  Here's what the timeline might look like:
    i1 = newItem({id:1});
    save({onComplete:cb1});
    i2 = newItem({id:2});
    save({onComplete:cb2});
    deleteItem(i1)
    save({onComplete:cb3});
    cb2();
    cb1();
    cb3();


Also had some thoughts about a few of the items on the agenda...

In Agenda Item 1, about pending API adjustments:
     I was hoping to also return the issue of whether we really want to 
support attribute-items as well as attribute-name-strings.  I know that 
the whole attribute-items thing was my fault to begin with, but now I 
see that it was a mistake.  And I see that even if dojo.data doesn't 
provide first-class support for attribute-items, apps like OpenRecord 
should still be able to add that feature in a separate layer wrapped 
around any existing datastore.  Would there be any objection to pulling 
the plug on supporting attribute-items?  If we're going to yank that 
feature, it would be good to do it before we've shipped 0.9, so we don't 
have to go through a deprecation cycle.

In Agenda Item 2, about adding a getLabel() method:
     I think there may be a parallel between the new getLabel() method 
and the existing getIdentity() method.  Having the getIdentity() method 
has led to demand for a getIdentityAttribute() method, and for parallel 
reasons I expect getLabel() will create a need for getLabelAttribute(). 
  Without a getLabelAttribute() method, there's no good way for a UI 
widget like a table to avoid displaying two copies of an item's label, 
and no good way to make the label editable.  Is a getLabelAttribute() 
method something we want to think about now?

In Agenda Item 2, about having a locale argument:
     It makes sense that the return value from getLabel() should depend 
on locale.  I think there are three other methods in the Read API where 
the return value would also depend on locale: getValue(), getValues(), 
and containsValue().  We could add locale arguments to all those 
methods, but that seems overly fine-grained.  Would it be better to 
instead have some way of setting the locale on the datastore as a whole, 
just once, so that you don't have to pass the same locale info in again 
and again, every time you want to get any value from the datastore?

In Agenda Item 7, about the JsonItemStore file format:
     I've been having second thoughts about the new file format that I 
floated for the JsonItemStore.  The new file format would make it much 
easier to represent hierachical data, but I think the new format would 
end up backing us into a corner when it comes to adding any other new 
features to the file format.  In particular, I'm worried about wanting 
to leave room to add support for data types like Dates, map locations, 
and URLs or web page links.


Probably we won't manage to get through all of this tomorrow, but I 
thought I should bring this stuff up sooner rather than later.

:o) Brian





More information about the dojo-contributors mailing list