@jesse it's not a problem for "us", it's a problem with users. Trust me it will be a headache for users judging from the mailing lists. Better if we inject, no fuss - since a version of the .js is tightly coupled with the .framework anyway. In a CLI world sure -- judging from our user-base, probably not. We can test this by removing the template for a version and see who complains :P
I'm not opposed to it, I just think if we want to change, might as well go for the best solution. However, we still haven't solved the "how do we detect they are using the wrong cordova version without going to the bridge", this however solves the "wrong platform cordova js in your www folder" problem. On Thu, May 3, 2012 at 12:51 PM, Jesse MacFadyen <[email protected]> wrote: > @shaz > I replied before reading yours... > > I don't see really what the problem is with having it be a resource to > the project... > The only issue I see is updating to a new version, the dev would have > to update the js file manually if they started from a template. > In a CLI world it would be trivial wouldn't it? > > I guess the part of this approach that I like is that it is > transparent, I do understand though that it may be 'not enough' > > > Cheers, > Jesse > > Sent from my iPhone5 > > On 2012-05-03, at 11:48 AM, Shazron <[email protected]> wrote: > >> Yeah - read my post again wrt to maintenance. How do you think the >> app/cordova.js gets in there in the bundle? It has to be a resource in >> the the Xcode project - a hard-coded thing. >> >> On Thu, May 3, 2012 at 11:46 AM, Jesse MacFadyen >> <[email protected]> wrote: >>> Actually, I was just saying that the device specific js file was >>> referenced from the parent folder to www That way when the dev >>> dropped their www into a different project it was still valid. >>> >>> I mean this: >>> <script src='../cordova-x.x.x.js'></script> >>> >>> So the package at runtime would look like: >>> app/cordova.js >>> app/www/index.html >>> >>> >>> The injection approach is interesting, but a much larger change and >>> potentially a long path until it works for all. Architecturally I like >>> it, but worry about the number of moving parts in the move from here >>> to there. >>> >>> Cheers, >>> Jesse >>> >>> Sent from my iPhone5 >>> >>> On 2012-05-03, at 11:22 AM, Filip Maj <[email protected]> wrote: >>> >>>> Are you saying, seeding the webview with the JS contents before loading >>>> app assets? We could even eliminate the need for having a <script> >>>> reference to cordova.js. >>>> >>>> BlackBerry can do that, and I think Drew, in his pure-plugin prototype >>>> [1], implemented that. >>>> >>>> Android in theory should be doable by calling loadUrl:<full cordova.js >>>> string here> on-load. >>>> >>>> All of this would need testing though. Would be nice! >>>> >>>> [1] https://github.com/deedubbu/cordova-blackberry-pluggable >>>> >>>> On 5/3/12 2:08 PM, "Jesse MacFadyen" <[email protected]> wrote: >>>> >>>>> Interesting. Good point in not depending on the bridge. >>>>> >>>>> Maybe slightly off topic, and a potential breaking change... >>>>> Does it make sense to place the cordova.js file up one level? Ie >>>>> src='../cordova-x.x.x.js' >>>>> This would make it a packaging issue, and the www folder would be >>>>> truly portable. >>>>> >>>>> Is this possible on other platforms? I know it would work for WP7 and iOS. >>>>> >>>>> Cheers, >>>>> Jesse >>>>> >>>>> Sent from my iPhone5 >>>>> >>>>> On 2012-05-03, at 10:48 AM, Filip Maj <[email protected]> wrote: >>>>> >>>>>> https://issues.apache.org/jira/browse/CB-385 >>>>>> >>>>>> Wanted to solicit the list to get help on the issue. Just trying to >>>>>> generate ideas. >>>>>> >>>>>> The core problem: people not using the proper .js file on their >>>>>> platform, >>>>>> I.e. Copying their entire www/ folder from their iOS app to their >>>>>> Android >>>>>> app. >>>>>> >>>>>> This issue proposes the idea of checking that the native platform the >>>>>> app >>>>>> is running on matches the platform the .js file is built for. >>>>>> >>>>>> The question is: how? >>>>>> >>>>>> One idea: could do checking in the device module (the one that returns >>>>>> device info) and compare against the platform id (from platform.js). >>>>>> However, this relies on the web view <-> native bridge working, which >>>>>> probably will not if the user is using the wrong .js file. >>>>>> >>>>>> >>>>>> >>>>>> >>>>
