[dojo-contributors] Dojo data discussion

Adam L. Peller adam at peller.org
Thu Jun 7 17:15:25 EDT 2007


I see your point, but is it really common to wrap localization in the
schema?  If so, and you want to encapsulate this in your data store,
you could just query dojo.i18n.normalizeLocale() to get the user's
locale, and you could optionally pass a locale (or any other
implementation-specific data) in with the data store object's
constructor.  I wouldn't try to fold this into the dojo.data APIs.
Beware that you have to do more than a match in your implementation --
you have to handle searches (en-us vs en, fallback, etc.)

So yeah, the database design I had in mind might be defined to return
some token to make localization more explicit, e.g.

{ id: 'facility123', country: 'countryDE'}

and then your UI code would delegate by doing the look up in a
localization table -- another database, or perhaps a json resource
designed for your locale (the latter is how Dojo does localization --
only your language comes over the wire).  I suppose even a two-stage
lookup could be encapsulated in a dojo.data datastore?  Making
localized references explicit isn't necessarily a bad thing.


On 6/7/07, Brian Douglas Skinner <skinner at dojotoolkit.org> wrote:
> Jon Sykes wrote:
> > Could you explain that a little more?
> >
> > It seems like in Data, any localization issues should be handled
> > in the actual data, not in the JS that accesses it.
> >
> > But I might be misunderstanding the example.
> Hmmm... I'm not sure I understand what you mean when you say
> "localization issues should be handled in the actual data, not in the JS
> that accesses it".
> Here's what I'm thinking...
> We will end up having lots of different datastore implementations
> designed to talk to different server-side data sources.  Some of those
> data sources will have a wealth of information available, including
> localization info about attribute values.
> For example, it would be easy to write a datastore based on the data
> available on the "CIA World Factbook" website.  In that dataset, the
> item representing Germany has attributes for short-name and long-name,
> with values in both English and German:
>    short-name: {en:'Germany', de:'Deutschland'},
>    long-name: {en:'Federal Republic of Germany',
>                de:'Bundesrepublik Deutschland'},
> So when you call store.getLabel(germany), the datastore could return
> either 'Germany' or 'Deutschland', depending on your locale.  The
> locale-specific filtering could happen either on the client or server,
> but I think we want the filtering to happen behind the dojo.data API
> (so, either on the server or within the datastore on the client), rather
> than letting the datastore return both 'Germany' and 'Deutschland' and
> leaving it to the UI to figure out which value to display.
> (The CIA World Factbook is probably a bad example, since it only has
> attribute values for a couple locales.  But other data sources have
> richer source data.)
> :o) Brian
> > On Jun 7, 2007, at 3:15 PM, Brian Douglas Skinner wrote:
> >
> >> Bill Keese wrote:
> >>> I'm lost.  I thought getLabel() for an employee record (for example)
> >>> would return the employee's name.  No localization needed.
> >> In the case of an employee's name, then probably no localization would
> >> be needed.  But in some other cases you might want localization.  For
> >> example, if you've got a set of items that represent countries and
> >> cities, those things might have different names in different
> >> languages.
> >>
> >> :o) Brian
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list