Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of gibson.becky@gmail.com
 designates 209.85.161.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAE6O_-bZ13Z-iJbbbMca12opSHfKEueHce9VPR1nyb2gZP7KQA@mail.gmail.com>
References: 
 <CAE6O_-bZ13Z-iJbbbMca12opSHfKEueHce9VPR1nyb2gZP7KQA@mail.gmail.com>
Date: Fri, 13 Apr 2012 15:23:51 -0400
Message-ID: 
 <CADjNb+mTmbSMaj2ECCzT7bzRumkP_r-1NR2spx8YFxtae9p93g@mail.gmail.com>
Subject: Re: [iOS] Factoring out JavaScript code from Objective-C
From: Becky Gibson <gibson.becky@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=485b397dd071a2d05804bd946988

--485b397dd071a2d05804bd946988
Content-Type: text/plain; charset=ISO-8859-1

I'm not sure that makes it any easier.  Yes, we can check for things like
Capital C Cordova, vs lower case c cordova, but it makes the actual coding
more disjoint IMHO.  Generally the strings are pretty specific to the
plugin. And, having them all in a separate file makes it harder to separate
out the plugin code.   I think what we really need is better testing
mechanisms to catch these type of errors.

my two cents,
-becky

On Fri, Apr 13, 2012 at 2:58 PM, Shazron <shazron@gmail.com> wrote:

> We currently have to write out JavaScript from Objective-C, and these
> strings can't be checked easily all in one place (note the bugs found
> today slated for 1.6.1)
>
> I'm proposing we either use:
> 1. NSLocalizedString [1][2] where the strings are in an external strings
> file
> 2. an Obj-C templating [3] solution that we need to create,
> essentially the same as 1 but with more features, although that's more
> complex
> 3. Move all the JS strings into an Obj-C file as string constants
>
> Items 1 and 2 require the .strings file to be in the user's
> application potentially (I haven't tested whether loading strings from
> the current framework bundle will work) and may be an upgrade
> nightmare (and we don't want users to edit them).
> Item 3 might be easiest, since it will all be baked-in.
>
> My preference is 1 (if the framework bundle loading works), then 3.
>
>
> [1] http://www.cocoadev.com/index.pl?NSLocalizedString
> [2] http://cocoawithlove.com/2011/04/user-interface-strings-in-cocoa.html
> [3] A bit of overkill though, Mustache for Obj-C:
> https://github.com/hiddenmemory/Tipi
>

--485b397dd071a2d05804bd946988--