Fair enough. And sorry I missed these replies. But what about my follow up question about the format functions. I asked about this on the Google Group too. Steve Atkin responded that he *thought* the idea was that you would use the result of the format functions in other JS libraries. It would be nice if someone on the PG team could *officially* confirm that is the intent (and even nicer if it was in the docs. ;) He also suggested Twitter's CLDR library would be an example of one that could use it:
Twitter CLDR https://github.com/twitter/twitter-cldr-js My main point here is - we have these functions in the Globalization API with no real direction as to their practical usage. They seem *perfect* for bypassing the async nature and would be much more practical, but the docs really should provide a bit more guidance I think. Anyway - I would love it if I could get confirmation on the above. On 3/28/13 9:24 AM, "Andrew Grieve" <agri...@chromium.org> wrote: >Yeah - if they require a call to exec(), then they have to be async. > > >On Thu, Mar 28, 2013 at 8:29 AM, Simon MacDonald ><simon.macdon...@gmail.com>wrote: > >> Yeah, I too think they could easily be sync methods. The only thing that >> I'd be concerned about is if there still is a limitation on iOS where it >> can't produce sync results. If that is the case I'd stay with a >>consistent >> API over sync returns. >> >> >> Simon Mac Donald >> http://hi.im/simonmacdonald >> >> >> On Wed, Mar 27, 2013 at 11:36 PM, Marcel Kinard <cmarc...@gmail.com> >> wrote: >> >> > When I look at all the methods in the Globalization API, they should >>all >> > execute quickly in a relatively predictable time period. They aren't >> going >> > off-box and aren't compute-heavy. So to me as a casual observer, >>having >> > them all run async seems like a bit of overkill. I'm not familiar with >> the >> > referenced patterns, but what would folks think about having a >> synchronous >> > version of these methods? Does that cut-the-chase and make it even >>more >> > simple than applying invocation patterns? >> > >> > -- Marcel >> > >> > On Mar 25, 2013, at 6:21 PM, Ray Camden <rayca...@adobe.com> wrote: >> > >> > > This possibly falls into the category of something that should be on >> the >> > > Google group (and actually I did ask there too ;) but I think it >>also >> > > exposes something not documented very well and maybe this discussion >> can >> > > lead to something that can be added to the docs. >> > > >> > > I've worked with the Globalization API before (well, for a blog >>post: >> > > >> > >> >>http://www.raymondcamden.com/index.cfm/2012/11/15/Testing-Globalization-S >>up >> > > port-in-PhoneGap-22). The API works great, but the async nature of >>it >> > > makes it very difficult for what I'd consider to be 'typical' usage. >> > > >> > > I'd imagine that - in many cases - a developer would have a set of >> > dynamic >> > > data, let's say sales figures, that they want to format for the end >> > user's >> > > locale. In order to do this with numberToString, they have to manage >> > async >> > > call backs for every request. Doable with deferreds, but not easy. >> > > >> > > I noticed this past week that part of the API describes getting back >> the >> > > pattern for formatting. For example: >> > > >> > > >> > >> >>http://docs.phonegap.com/en/2.5.0/cordova_globalization_globalization.md. >>ht >> > > ml#globalization.getNumberPattern >> > > >> > > >> > > So my immediate thought was - cool - I could use this and then apply >> the >> > > formats to numbers in a simpler sync process. But it isn't >>documented >> how >> > > one actually *uses* these patterns. I'm thinking it may be obvious >> (hence >> > > the lack of documentation), but if anyone could give me a hand to >> > > understanding it I'd greatly appreciate it. >> > > >> > > -Raymond Camden >> > > >> > >> > >>
