In the case of android and bb (I think) we have tried to avoid JS in the actual plugin code by using the PluginResult.toSuccessCallbackString method that is (ideally) the only place (and toErrorCallbackString of course) that JS code is used in native.
On Fri, Apr 13, 2012 at 12:37 PM, Shazron <[email protected]> wrote: > Just had the same thought after I sent that email - precisely since > all our stuff is "self-contained" in plugins, separating them out and > adding a dependency will add on to the work we would have to do. > > I added manual tests to the release checklist: > Step 2 of http://wiki.apache.org/cordova/IOSReleaseChecklist > http://wiki.apache.org/cordova/iOSManualTests > > On Fri, Apr 13, 2012 at 12:23 PM, Becky Gibson <[email protected]> wrote: >> 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 <[email protected]> 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 >>>
