[dojo-contributors] Dojo data discussion

Jared Jurkiewicz jared.jurkiewicz at gmail.com
Tue Jun 5 16:06:46 EDT 2007


Adam,
   That's also one of my concerns.  If the user really wants to localize the
labels and such, they can do so by over-riding the function with
localization info.  Otherwise I think we're opening one really huge back of
worms.

-- Jared


On 6/5/07, Adam L. Peller <adam at peller.org> wrote:
>
> Hmm... I just caught this and really don't know anything about the
> getLabel() API but I'd say keeping localizable data out of the API
> would be a win.  It's a very complex requirement and if you can stay
> locale-agnostic and push the problem off as a separate query, you're
> much better off, IMO.  Perhaps you could use separate resource bundles
> to describe your data, if that's what your after.
>
> -Adam
>
>
> 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
> >
> >
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at dojotoolkit.org
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20070605/c156842c/attachment.htm 


More information about the dojo-contributors mailing list