[dojo-contributors] Dojo data discussion

Jared Jurkiewicz jared.jurkiewicz at gmail.com
Tue Jun 5 10:11:57 EDT 2007

   Agenda updated.  Comments added regarding some of them to the agenda.

-- Jared

On 6/5/07, Brian Douglas Skinner <skinner at dojotoolkit.org> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20070605/18cee972/attachment.htm 

More information about the dojo-contributors mailing list