[dojo-contributors] Dojo data discussion

Bill Keese bill at dojotoolkit.org
Tue Jun 5 22:54:29 EDT 2007


I'm lost.  I thought getLabel() for an employee record (for example) 
would return the employee's name.  No localization needed.

Jared Jurkiewicz wrote:
> 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 <mailto: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
>     <mailto: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
>     <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
>     <mailto:dojo-contributors at dojotoolkit.org>
>      > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>      >
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors



More information about the dojo-contributors mailing list