[dojo-contributors] Dojo data discussion

Owen Williams 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.

thoughts?
O


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
>> question.
>
> 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 mailing list