cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Camden <rayca...@adobe.com>
Subject Re: Question about the Globalization APi
Date Tue, 02 Apr 2013 15:27:24 GMT
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" <agrieve@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.macdonald@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 <cmarcelk@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 <raycamde@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
>> > >
>> >
>> >
>>


Mime
View raw message