[dojo-contributors] Dojo data discussion
owen at smartsoul.com
Thu Jun 7 17:42:49 EDT 2007
I can definitely see both sides of this argument -- dojo.data would,
optimally, hide all of the messy details of such localization stuff
when possible. But Adam's right that localization it's a big tar
ball to try to swallow in the general case.
I think in pretty much all cases, the user of the dojo.data apis will
have to know that they're dealing with locale-capable data sources,
so making them do a small amount of extra work to get the locale-
specific data doesn't seem too bad.
I can see two possible solutions that don't muddy the waters too much:
1) Treat "locale" as any other property that can be sent to a
query. We have a routine to get the locale of the browser, so if the
app developer knows that their data source (client or server) has
locale-specific strings, they can pass "locale" as a normal property
in their store.fetch() call. If desired, we could have a property
in the datasource "base classes" that, when set, automatically
includes the locale in all queries.
2) Have a subclass or mixin "dojo.data.LocaleStore" which can be
used when the data has localizations, encapsulating whatever patterns
we determine make sense. We might even have multiple mix-ins for
handling different patterns.
On Jun 7, 2007, at 2:19 PM, Brian Douglas Skinner wrote:
> Jon Sykes wrote:
>> But surely this is not a localization idea, it's a data format
> Yes, maybe "localization" is the wrong word to be using to talk about
> all this -- we're just talking about data access.
> But I'm not sure that it's a data format question either. Ideally the
> dojo.data API serves as an abstraction that hides whatever underlying
> data formats it's using.
More information about the dojo-contributors