Re: Fast edit-refresh cycles
Ya, more I've thought on the more I think as long as we're using the config.xml (or likewise some manifest) as the canonical src for the concat then this should be an ok convention. While we are concatenating everything today its easy to know what's in there *because* we concat _everything_. In the future, when plugins are separated out from core, and ppl are composing their own builds, its likely plugins will be independently versioned, which could get ugly if we don't have a way of identifying exactly what is going into their build. On Fri, Nov 23, 2012 at 8:01 PM, Anis KADRI wrote: > I don't see what the problem is with having all plugins concatenated in one > file. I'd even go further and say that we should just concatenate all of it > in cordova.js (that is what is happening right now with core plugins). > We would not be disallowing people from having multiple script tags if they > wanted to. We would just be using one approach to solve the automatic > installation of plugins and I believe that re-generating a javascript file > is certainly easier and faster than editing script tags in html files. > People would still be able to manually install plugins, add script tags for > themetc ITIZDAWEB. > > > On Fri, Nov 23, 2012 at 10:07 AM, Andrew Grieve >wrote: > > > Something else along these lines we should consider - is providing a > > grunt.js file in the default template when you run cordova create. It > could > > have a watch task that copies files from the root www/ into platform www/ > > directories whenever a file changes. > > > > > > On Fri, Nov 23, 2012 at 10:29 AM, Gord Tanner wrote: > > > > > I have always had a vision that the build step for cordova.js would > make > > it > > > into the app build step. > > > > > > Currently the packager has most of the functionality to bundle in > > plugins / > > > platform specific code / core modules. > > > > > > With a little bit of work it could be made to be driven off of the > > plugin's > > > folder for 3rd party code and the manifest for core modules. > > > > > > > > > > > > > > > On Fri, Nov 23, 2012 at 10:20 AM, Brian LeRoux wrote: > > > > > > > just considering this, I suppose we could say that cordova.js is a > > build > > > > artifact, and the manifest is the 'truth' of the install (from the > > issue > > > > tracking perspective) > > > > > > > > > > > > On Fri, Nov 23, 2012 at 3:09 PM, Braden Shepherdson < > > bra...@chromium.org > > > > >wrote: > > > > > > > > > I'm happy adding multiple script tags. We could require plugins to > be > > > > > wrapped up for AMD, instead, and just include them in the index > page. > > > > > > > > > > I don't think a single file makes the reproducibility any worse: > you > > > > still > > > > > need to have the exact set and versions of plugins that anyone else > > > has. > > > > > > > > > > And it's not strictly a build step, that's being deliberately > > avoided. > > > > It's > > > > > a plugin-install-time step that comes at the end of every plugin > add > > or > > > > rm. > > > > > > > > > > Braden > > > > > > > > > > > > > > > On Fri, Nov 23, 2012 at 10:02 AM, Brian LeRoux wrote: > > > > > > > > > > > So, we have a build step no matter what. Currently we concat the > > > whole > > > > > go. > > > > > > When we have the many plugins world doing a fat concat is > dangerous > > > > > > business for issue tracking. My cordova.js very likely won't be > the > > > > same > > > > > as > > > > > > yours. Moving this into a second file has the same problem. > > > > > > > > > > > > Script loaders are a touchy subject. General consensus is that > > > browsers > > > > > > prefer AMD but I think most folks really just chuck in a bunch of > > > > script > > > > > > tags. This is not ideal, but I really feel we should not be > > dictating > > > > how > > > > > > ppl build their apps, and I do want to see a super slim > cordova.js > > > > > > file---and leave the inclusion of plugins as an exercise for the > > > > > > developers. > > > > > > > > > > > > Now THAT said, we could encourage a sensible default in > > > cordova-client. > > > > > > > > > > > > > > > > > > On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve < > > agri...@chromium.org > > > > > > > > > > wrote: > > > > > > > > > > > > > On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner < > gtan...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > This also is feeding into some of the work we are doing with > > > > ripple. > > > > > > > > > > > > > > > > Ripple will serve up the app and host it kind of like how we > do > > > > > > > > debug.phonegap.com for in browser testing. > > > > > > > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > > > > > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > > > > > > > > > > > > > > > Agree with Jesse. > > > > > > > > > > > > > > > > > > Automatically adding the plugin's .js to html pages inside > a > > > www > > > > > dir > > > > > > > can > > > > > > > > > be done by the cordova-client tool anyways. > >
Re: Fast edit-refresh cycles
I don't see what the problem is with having all plugins concatenated in one file. I'd even go further and say that we should just concatenate all of it in cordova.js (that is what is happening right now with core plugins). We would not be disallowing people from having multiple script tags if they wanted to. We would just be using one approach to solve the automatic installation of plugins and I believe that re-generating a javascript file is certainly easier and faster than editing script tags in html files. People would still be able to manually install plugins, add script tags for themetc ITIZDAWEB. On Fri, Nov 23, 2012 at 10:07 AM, Andrew Grieve wrote: > Something else along these lines we should consider - is providing a > grunt.js file in the default template when you run cordova create. It could > have a watch task that copies files from the root www/ into platform www/ > directories whenever a file changes. > > > On Fri, Nov 23, 2012 at 10:29 AM, Gord Tanner wrote: > > > I have always had a vision that the build step for cordova.js would make > it > > into the app build step. > > > > Currently the packager has most of the functionality to bundle in > plugins / > > platform specific code / core modules. > > > > With a little bit of work it could be made to be driven off of the > plugin's > > folder for 3rd party code and the manifest for core modules. > > > > > > > > > > On Fri, Nov 23, 2012 at 10:20 AM, Brian LeRoux wrote: > > > > > just considering this, I suppose we could say that cordova.js is a > build > > > artifact, and the manifest is the 'truth' of the install (from the > issue > > > tracking perspective) > > > > > > > > > On Fri, Nov 23, 2012 at 3:09 PM, Braden Shepherdson < > bra...@chromium.org > > > >wrote: > > > > > > > I'm happy adding multiple script tags. We could require plugins to be > > > > wrapped up for AMD, instead, and just include them in the index page. > > > > > > > > I don't think a single file makes the reproducibility any worse: you > > > still > > > > need to have the exact set and versions of plugins that anyone else > > has. > > > > > > > > And it's not strictly a build step, that's being deliberately > avoided. > > > It's > > > > a plugin-install-time step that comes at the end of every plugin add > or > > > rm. > > > > > > > > Braden > > > > > > > > > > > > On Fri, Nov 23, 2012 at 10:02 AM, Brian LeRoux wrote: > > > > > > > > > So, we have a build step no matter what. Currently we concat the > > whole > > > > go. > > > > > When we have the many plugins world doing a fat concat is dangerous > > > > > business for issue tracking. My cordova.js very likely won't be the > > > same > > > > as > > > > > yours. Moving this into a second file has the same problem. > > > > > > > > > > Script loaders are a touchy subject. General consensus is that > > browsers > > > > > prefer AMD but I think most folks really just chuck in a bunch of > > > script > > > > > tags. This is not ideal, but I really feel we should not be > dictating > > > how > > > > > ppl build their apps, and I do want to see a super slim cordova.js > > > > > file---and leave the inclusion of plugins as an exercise for the > > > > > developers. > > > > > > > > > > Now THAT said, we could encourage a sensible default in > > cordova-client. > > > > > > > > > > > > > > > On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve < > agri...@chromium.org > > > > > > > > wrote: > > > > > > > > > > > On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner > > > > wrote: > > > > > > > > > > > > > This also is feeding into some of the work we are doing with > > > ripple. > > > > > > > > > > > > > > Ripple will serve up the app and host it kind of like how we do > > > > > > > debug.phonegap.com for in browser testing. > > > > > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > > > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > > > > > > > > > > > > > Agree with Jesse. > > > > > > > > > > > > > > > > Automatically adding the plugin's .js to html pages inside a > > www > > > > dir > > > > > > can > > > > > > > > be done by the cordova-client tool anyways. > > > > > > > > > > > > > > > > Agree this should go to vote before we proceed. > > > > > > > > > > > > > > > > On 11/22/12 12:13 PM, "Jesse" > wrote: > > > > > > > > > > > > > > > >> I think all the refresh stuff is super cool, I will share > how > > I > > > > > work, > > > > > > > >> so you can get another perspective. > > > > > > > >> 90% of my code is written on localhost, either running > > directly > > > > in a > > > > > > > >> browser to work out UI stuff. > > > > > > > >> When I need access to actual device APIs, I simply put a > > > redirect > > > > in > > > > > > > >> my index.html. > > > > > > > >> This gets me through 99% of my work, after which I can fine > > tune > > > > an > > > > > > > >> individual device or functional piece in XCode, Eclipse, > > Visual > > > > > > > >> Studio, et al > > > > > > > > > > > > > Awesome! This is the workflow we want t
Re: Fast edit-refresh cycles
Something else along these lines we should consider - is providing a grunt.js file in the default template when you run cordova create. It could have a watch task that copies files from the root www/ into platform www/ directories whenever a file changes. On Fri, Nov 23, 2012 at 10:29 AM, Gord Tanner wrote: > I have always had a vision that the build step for cordova.js would make it > into the app build step. > > Currently the packager has most of the functionality to bundle in plugins / > platform specific code / core modules. > > With a little bit of work it could be made to be driven off of the plugin's > folder for 3rd party code and the manifest for core modules. > > > > > On Fri, Nov 23, 2012 at 10:20 AM, Brian LeRoux wrote: > > > just considering this, I suppose we could say that cordova.js is a build > > artifact, and the manifest is the 'truth' of the install (from the issue > > tracking perspective) > > > > > > On Fri, Nov 23, 2012 at 3:09 PM, Braden Shepherdson > >wrote: > > > > > I'm happy adding multiple script tags. We could require plugins to be > > > wrapped up for AMD, instead, and just include them in the index page. > > > > > > I don't think a single file makes the reproducibility any worse: you > > still > > > need to have the exact set and versions of plugins that anyone else > has. > > > > > > And it's not strictly a build step, that's being deliberately avoided. > > It's > > > a plugin-install-time step that comes at the end of every plugin add or > > rm. > > > > > > Braden > > > > > > > > > On Fri, Nov 23, 2012 at 10:02 AM, Brian LeRoux wrote: > > > > > > > So, we have a build step no matter what. Currently we concat the > whole > > > go. > > > > When we have the many plugins world doing a fat concat is dangerous > > > > business for issue tracking. My cordova.js very likely won't be the > > same > > > as > > > > yours. Moving this into a second file has the same problem. > > > > > > > > Script loaders are a touchy subject. General consensus is that > browsers > > > > prefer AMD but I think most folks really just chuck in a bunch of > > script > > > > tags. This is not ideal, but I really feel we should not be dictating > > how > > > > ppl build their apps, and I do want to see a super slim cordova.js > > > > file---and leave the inclusion of plugins as an exercise for the > > > > developers. > > > > > > > > Now THAT said, we could encourage a sensible default in > cordova-client. > > > > > > > > > > > > On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve > > > > > wrote: > > > > > > > > > On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner > > > wrote: > > > > > > > > > > > This also is feeding into some of the work we are doing with > > ripple. > > > > > > > > > > > > Ripple will serve up the app and host it kind of like how we do > > > > > > debug.phonegap.com for in browser testing. > > > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > > > > > > > > > > > Agree with Jesse. > > > > > > > > > > > > > > Automatically adding the plugin's .js to html pages inside a > www > > > dir > > > > > can > > > > > > > be done by the cordova-client tool anyways. > > > > > > > > > > > > > > Agree this should go to vote before we proceed. > > > > > > > > > > > > > > On 11/22/12 12:13 PM, "Jesse" wrote: > > > > > > > > > > > > > >> I think all the refresh stuff is super cool, I will share how > I > > > > work, > > > > > > >> so you can get another perspective. > > > > > > >> 90% of my code is written on localhost, either running > directly > > > in a > > > > > > >> browser to work out UI stuff. > > > > > > >> When I need access to actual device APIs, I simply put a > > redirect > > > in > > > > > > >> my index.html. > > > > > > >> This gets me through 99% of my work, after which I can fine > tune > > > an > > > > > > >> individual device or functional piece in XCode, Eclipse, > Visual > > > > > > >> Studio, et al > > > > > > > > > > > Awesome! This is the workflow we want to encourage via "cordova > > serve". > > > > > > > > > > > > > > > > >> > > > > > > >> When it comes to inclusion of multiple script tags, I do not > see > > > > this > > > > > > >> as a barrier at all. This is the way the internet has always > > > > worked, > > > > > > >> and it ain't broke. > > > > > > >> I like the explicit declaration of having a script tag, plus > you > > > can > > > > > > >> have multiple pages, with different plugin requirements. > Adding > > > an > > > > > > >> extra build step, + reinventing the internet inside our > > framework > > > is > > > > > > >> madness in my opinion. > > > > > > > > > > > madness is maybe a bit of an exaggeration :) > > > > > > > > > > Our "cordova plugin add" tool already adds the necessary plugin > line > > to > > > > > your config.xml / cordova.plist *and* edits your xcode project file > > to > > > > add > > > > > the native files. Why have the tool take care of these manual steps > > on > > > > the > > > > >
Re: Fast edit-refresh cycles
I have always had a vision that the build step for cordova.js would make it into the app build step. Currently the packager has most of the functionality to bundle in plugins / platform specific code / core modules. With a little bit of work it could be made to be driven off of the plugin's folder for 3rd party code and the manifest for core modules. On Fri, Nov 23, 2012 at 10:20 AM, Brian LeRoux wrote: > just considering this, I suppose we could say that cordova.js is a build > artifact, and the manifest is the 'truth' of the install (from the issue > tracking perspective) > > > On Fri, Nov 23, 2012 at 3:09 PM, Braden Shepherdson >wrote: > > > I'm happy adding multiple script tags. We could require plugins to be > > wrapped up for AMD, instead, and just include them in the index page. > > > > I don't think a single file makes the reproducibility any worse: you > still > > need to have the exact set and versions of plugins that anyone else has. > > > > And it's not strictly a build step, that's being deliberately avoided. > It's > > a plugin-install-time step that comes at the end of every plugin add or > rm. > > > > Braden > > > > > > On Fri, Nov 23, 2012 at 10:02 AM, Brian LeRoux wrote: > > > > > So, we have a build step no matter what. Currently we concat the whole > > go. > > > When we have the many plugins world doing a fat concat is dangerous > > > business for issue tracking. My cordova.js very likely won't be the > same > > as > > > yours. Moving this into a second file has the same problem. > > > > > > Script loaders are a touchy subject. General consensus is that browsers > > > prefer AMD but I think most folks really just chuck in a bunch of > script > > > tags. This is not ideal, but I really feel we should not be dictating > how > > > ppl build their apps, and I do want to see a super slim cordova.js > > > file---and leave the inclusion of plugins as an exercise for the > > > developers. > > > > > > Now THAT said, we could encourage a sensible default in cordova-client. > > > > > > > > > On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve > > > wrote: > > > > > > > On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner > > wrote: > > > > > > > > > This also is feeding into some of the work we are doing with > ripple. > > > > > > > > > > Ripple will serve up the app and host it kind of like how we do > > > > > debug.phonegap.com for in browser testing. > > > > > > > > > > Sent from my iPhone > > > > > > > > > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > > > > > > > > > Agree with Jesse. > > > > > > > > > > > > Automatically adding the plugin's .js to html pages inside a www > > dir > > > > can > > > > > > be done by the cordova-client tool anyways. > > > > > > > > > > > > Agree this should go to vote before we proceed. > > > > > > > > > > > > On 11/22/12 12:13 PM, "Jesse" wrote: > > > > > > > > > > > >> I think all the refresh stuff is super cool, I will share how I > > > work, > > > > > >> so you can get another perspective. > > > > > >> 90% of my code is written on localhost, either running directly > > in a > > > > > >> browser to work out UI stuff. > > > > > >> When I need access to actual device APIs, I simply put a > redirect > > in > > > > > >> my index.html. > > > > > >> This gets me through 99% of my work, after which I can fine tune > > an > > > > > >> individual device or functional piece in XCode, Eclipse, Visual > > > > > >> Studio, et al > > > > > > > > > Awesome! This is the workflow we want to encourage via "cordova > serve". > > > > > > > > > > > > > >> > > > > > >> When it comes to inclusion of multiple script tags, I do not see > > > this > > > > > >> as a barrier at all. This is the way the internet has always > > > worked, > > > > > >> and it ain't broke. > > > > > >> I like the explicit declaration of having a script tag, plus you > > can > > > > > >> have multiple pages, with different plugin requirements. Adding > > an > > > > > >> extra build step, + reinventing the internet inside our > framework > > is > > > > > >> madness in my opinion. > > > > > > > > > madness is maybe a bit of an exaggeration :) > > > > > > > > Our "cordova plugin add" tool already adds the necessary plugin line > to > > > > your config.xml / cordova.plist *and* edits your xcode project file > to > > > add > > > > the native files. Why have the tool take care of these manual steps > on > > > the > > > > native side, but not the HTML side? It's a pain to have to make > manual > > > > edits to your .html file every time you add or remove a plugin. > > > > > > > > I see this more as removing a step rather than adding a step. I'm not > > set > > > > on having a single plugins-concat.js file, but it *is* what we > already > > do > > > > for our cordova.js file (we don't list each source file separately in > > > this > > > > case). > > > > > > > > From your response, it's not clear to me if you disagree with the > > desire > > > to > > > > remove this manual step in the plugin install/uninstall
Re: Fast edit-refresh cycles
just considering this, I suppose we could say that cordova.js is a build artifact, and the manifest is the 'truth' of the install (from the issue tracking perspective) On Fri, Nov 23, 2012 at 3:09 PM, Braden Shepherdson wrote: > I'm happy adding multiple script tags. We could require plugins to be > wrapped up for AMD, instead, and just include them in the index page. > > I don't think a single file makes the reproducibility any worse: you still > need to have the exact set and versions of plugins that anyone else has. > > And it's not strictly a build step, that's being deliberately avoided. It's > a plugin-install-time step that comes at the end of every plugin add or rm. > > Braden > > > On Fri, Nov 23, 2012 at 10:02 AM, Brian LeRoux wrote: > > > So, we have a build step no matter what. Currently we concat the whole > go. > > When we have the many plugins world doing a fat concat is dangerous > > business for issue tracking. My cordova.js very likely won't be the same > as > > yours. Moving this into a second file has the same problem. > > > > Script loaders are a touchy subject. General consensus is that browsers > > prefer AMD but I think most folks really just chuck in a bunch of script > > tags. This is not ideal, but I really feel we should not be dictating how > > ppl build their apps, and I do want to see a super slim cordova.js > > file---and leave the inclusion of plugins as an exercise for the > > developers. > > > > Now THAT said, we could encourage a sensible default in cordova-client. > > > > > > On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve > > wrote: > > > > > On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner > wrote: > > > > > > > This also is feeding into some of the work we are doing with ripple. > > > > > > > > Ripple will serve up the app and host it kind of like how we do > > > > debug.phonegap.com for in browser testing. > > > > > > > > Sent from my iPhone > > > > > > > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > > > > > > > Agree with Jesse. > > > > > > > > > > Automatically adding the plugin's .js to html pages inside a www > dir > > > can > > > > > be done by the cordova-client tool anyways. > > > > > > > > > > Agree this should go to vote before we proceed. > > > > > > > > > > On 11/22/12 12:13 PM, "Jesse" wrote: > > > > > > > > > >> I think all the refresh stuff is super cool, I will share how I > > work, > > > > >> so you can get another perspective. > > > > >> 90% of my code is written on localhost, either running directly > in a > > > > >> browser to work out UI stuff. > > > > >> When I need access to actual device APIs, I simply put a redirect > in > > > > >> my index.html. > > > > >> This gets me through 99% of my work, after which I can fine tune > an > > > > >> individual device or functional piece in XCode, Eclipse, Visual > > > > >> Studio, et al > > > > > > > Awesome! This is the workflow we want to encourage via "cordova serve". > > > > > > > > > > >> > > > > >> When it comes to inclusion of multiple script tags, I do not see > > this > > > > >> as a barrier at all. This is the way the internet has always > > worked, > > > > >> and it ain't broke. > > > > >> I like the explicit declaration of having a script tag, plus you > can > > > > >> have multiple pages, with different plugin requirements. Adding > an > > > > >> extra build step, + reinventing the internet inside our framework > is > > > > >> madness in my opinion. > > > > > > > madness is maybe a bit of an exaggeration :) > > > > > > Our "cordova plugin add" tool already adds the necessary plugin line to > > > your config.xml / cordova.plist *and* edits your xcode project file to > > add > > > the native files. Why have the tool take care of these manual steps on > > the > > > native side, but not the HTML side? It's a pain to have to make manual > > > edits to your .html file every time you add or remove a plugin. > > > > > > I see this more as removing a step rather than adding a step. I'm not > set > > > on having a single plugins-concat.js file, but it *is* what we already > do > > > for our cordova.js file (we don't list each source file separately in > > this > > > case). > > > > > > From your response, it's not clear to me if you disagree with the > desire > > to > > > remove this manual step in the plugin install/uninstall process, or if > > you > > > just disagree with the proposed approach of achieving this through > > > concatenating plugin JS into a single file. > > > > > > You can't have different web-pages with different plugins enabled on > the > > > native side, I don't think there would be much benefit to enable this > > > use-case for just the HTML side. Do you have any example of when you'd > > want > > > this? > > > > > > Votes are fine, but consensus is much better. I don't want to move > > forward > > > with this until everyone is on board. > > > > > > > > > > >> > > > > >> This of course does not preclude use of this technique, however, I > > > > >> feel very strongly tha
Re: Fast edit-refresh cycles
I'm happy adding multiple script tags. We could require plugins to be wrapped up for AMD, instead, and just include them in the index page. I don't think a single file makes the reproducibility any worse: you still need to have the exact set and versions of plugins that anyone else has. And it's not strictly a build step, that's being deliberately avoided. It's a plugin-install-time step that comes at the end of every plugin add or rm. Braden On Fri, Nov 23, 2012 at 10:02 AM, Brian LeRoux wrote: > So, we have a build step no matter what. Currently we concat the whole go. > When we have the many plugins world doing a fat concat is dangerous > business for issue tracking. My cordova.js very likely won't be the same as > yours. Moving this into a second file has the same problem. > > Script loaders are a touchy subject. General consensus is that browsers > prefer AMD but I think most folks really just chuck in a bunch of script > tags. This is not ideal, but I really feel we should not be dictating how > ppl build their apps, and I do want to see a super slim cordova.js > file---and leave the inclusion of plugins as an exercise for the > developers. > > Now THAT said, we could encourage a sensible default in cordova-client. > > > On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve > wrote: > > > On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner wrote: > > > > > This also is feeding into some of the work we are doing with ripple. > > > > > > Ripple will serve up the app and host it kind of like how we do > > > debug.phonegap.com for in browser testing. > > > > > > Sent from my iPhone > > > > > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > > > > > Agree with Jesse. > > > > > > > > Automatically adding the plugin's .js to html pages inside a www dir > > can > > > > be done by the cordova-client tool anyways. > > > > > > > > Agree this should go to vote before we proceed. > > > > > > > > On 11/22/12 12:13 PM, "Jesse" wrote: > > > > > > > >> I think all the refresh stuff is super cool, I will share how I > work, > > > >> so you can get another perspective. > > > >> 90% of my code is written on localhost, either running directly in a > > > >> browser to work out UI stuff. > > > >> When I need access to actual device APIs, I simply put a redirect in > > > >> my index.html. > > > >> This gets me through 99% of my work, after which I can fine tune an > > > >> individual device or functional piece in XCode, Eclipse, Visual > > > >> Studio, et al > > > > > Awesome! This is the workflow we want to encourage via "cordova serve". > > > > > > > >> > > > >> When it comes to inclusion of multiple script tags, I do not see > this > > > >> as a barrier at all. This is the way the internet has always > worked, > > > >> and it ain't broke. > > > >> I like the explicit declaration of having a script tag, plus you can > > > >> have multiple pages, with different plugin requirements. Adding an > > > >> extra build step, + reinventing the internet inside our framework is > > > >> madness in my opinion. > > > > > madness is maybe a bit of an exaggeration :) > > > > Our "cordova plugin add" tool already adds the necessary plugin line to > > your config.xml / cordova.plist *and* edits your xcode project file to > add > > the native files. Why have the tool take care of these manual steps on > the > > native side, but not the HTML side? It's a pain to have to make manual > > edits to your .html file every time you add or remove a plugin. > > > > I see this more as removing a step rather than adding a step. I'm not set > > on having a single plugins-concat.js file, but it *is* what we already do > > for our cordova.js file (we don't list each source file separately in > this > > case). > > > > From your response, it's not clear to me if you disagree with the desire > to > > remove this manual step in the plugin install/uninstall process, or if > you > > just disagree with the proposed approach of achieving this through > > concatenating plugin JS into a single file. > > > > You can't have different web-pages with different plugins enabled on the > > native side, I don't think there would be much benefit to enable this > > use-case for just the HTML side. Do you have any example of when you'd > want > > this? > > > > Votes are fine, but consensus is much better. I don't want to move > forward > > with this until everyone is on board. > > > > > > > >> > > > >> This of course does not preclude use of this technique, however, I > > > >> feel very strongly that we should NOT be building this into our > > > >> framework, and forcing developers to use this approach. I think > this > > > >> is definitely something that we should vote on before developing > > > >> further if the goal is inclusion in cordova. > > > >> > > > >> Cheers, > > > >> Jesse > > > >> > > > >> > > > >> On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux wrote: > > > >>> super interesting. I like where this is going. > > > >>> > > > >>> > > > >>> On Thu, Nov 22, 2012 a
Re: Fast edit-refresh cycles
So, we have a build step no matter what. Currently we concat the whole go. When we have the many plugins world doing a fat concat is dangerous business for issue tracking. My cordova.js very likely won't be the same as yours. Moving this into a second file has the same problem. Script loaders are a touchy subject. General consensus is that browsers prefer AMD but I think most folks really just chuck in a bunch of script tags. This is not ideal, but I really feel we should not be dictating how ppl build their apps, and I do want to see a super slim cordova.js file---and leave the inclusion of plugins as an exercise for the developers. Now THAT said, we could encourage a sensible default in cordova-client. On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve wrote: > On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner wrote: > > > This also is feeding into some of the work we are doing with ripple. > > > > Ripple will serve up the app and host it kind of like how we do > > debug.phonegap.com for in browser testing. > > > > Sent from my iPhone > > > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > > > Agree with Jesse. > > > > > > Automatically adding the plugin's .js to html pages inside a www dir > can > > > be done by the cordova-client tool anyways. > > > > > > Agree this should go to vote before we proceed. > > > > > > On 11/22/12 12:13 PM, "Jesse" wrote: > > > > > >> I think all the refresh stuff is super cool, I will share how I work, > > >> so you can get another perspective. > > >> 90% of my code is written on localhost, either running directly in a > > >> browser to work out UI stuff. > > >> When I need access to actual device APIs, I simply put a redirect in > > >> my index.html. > > >> This gets me through 99% of my work, after which I can fine tune an > > >> individual device or functional piece in XCode, Eclipse, Visual > > >> Studio, et al > > > Awesome! This is the workflow we want to encourage via "cordova serve". > > > > >> > > >> When it comes to inclusion of multiple script tags, I do not see this > > >> as a barrier at all. This is the way the internet has always worked, > > >> and it ain't broke. > > >> I like the explicit declaration of having a script tag, plus you can > > >> have multiple pages, with different plugin requirements. Adding an > > >> extra build step, + reinventing the internet inside our framework is > > >> madness in my opinion. > > > madness is maybe a bit of an exaggeration :) > > Our "cordova plugin add" tool already adds the necessary plugin line to > your config.xml / cordova.plist *and* edits your xcode project file to add > the native files. Why have the tool take care of these manual steps on the > native side, but not the HTML side? It's a pain to have to make manual > edits to your .html file every time you add or remove a plugin. > > I see this more as removing a step rather than adding a step. I'm not set > on having a single plugins-concat.js file, but it *is* what we already do > for our cordova.js file (we don't list each source file separately in this > case). > > From your response, it's not clear to me if you disagree with the desire to > remove this manual step in the plugin install/uninstall process, or if you > just disagree with the proposed approach of achieving this through > concatenating plugin JS into a single file. > > You can't have different web-pages with different plugins enabled on the > native side, I don't think there would be much benefit to enable this > use-case for just the HTML side. Do you have any example of when you'd want > this? > > Votes are fine, but consensus is much better. I don't want to move forward > with this until everyone is on board. > > > > >> > > >> This of course does not preclude use of this technique, however, I > > >> feel very strongly that we should NOT be building this into our > > >> framework, and forcing developers to use this approach. I think this > > >> is definitely something that we should vote on before developing > > >> further if the goal is inclusion in cordova. > > >> > > >> Cheers, > > >> Jesse > > >> > > >> > > >> On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux wrote: > > >>> super interesting. I like where this is going. > > >>> > > >>> > > >>> On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve > > > >>> wrote: > > >>> > > On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj wrote: > > > > > Dude: awesome! > > > > > > My answers in-line: > > > > > >> 2. Manually adding the
Re: Fast edit-refresh cycles
On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner wrote: > This also is feeding into some of the work we are doing with ripple. > > Ripple will serve up the app and host it kind of like how we do > debug.phonegap.com for in browser testing. > > Sent from my iPhone > > On 2012-11-22, at 3:15 PM, Filip Maj wrote: > > > Agree with Jesse. > > > > Automatically adding the plugin's .js to html pages inside a www dir can > > be done by the cordova-client tool anyways. > > > > Agree this should go to vote before we proceed. > > > > On 11/22/12 12:13 PM, "Jesse" wrote: > > > >> I think all the refresh stuff is super cool, I will share how I work, > >> so you can get another perspective. > >> 90% of my code is written on localhost, either running directly in a > >> browser to work out UI stuff. > >> When I need access to actual device APIs, I simply put a redirect in > >> my index.html. > >> This gets me through 99% of my work, after which I can fine tune an > >> individual device or functional piece in XCode, Eclipse, Visual > >> Studio, et al > Awesome! This is the workflow we want to encourage via "cordova serve". > >> > >> When it comes to inclusion of multiple script tags, I do not see this > >> as a barrier at all. This is the way the internet has always worked, > >> and it ain't broke. > >> I like the explicit declaration of having a script tag, plus you can > >> have multiple pages, with different plugin requirements. Adding an > >> extra build step, + reinventing the internet inside our framework is > >> madness in my opinion. > madness is maybe a bit of an exaggeration :) Our "cordova plugin add" tool already adds the necessary plugin line to your config.xml / cordova.plist *and* edits your xcode project file to add the native files. Why have the tool take care of these manual steps on the native side, but not the HTML side? It's a pain to have to make manual edits to your .html file every time you add or remove a plugin. I see this more as removing a step rather than adding a step. I'm not set on having a single plugins-concat.js file, but it *is* what we already do for our cordova.js file (we don't list each source file separately in this case). >From your response, it's not clear to me if you disagree with the desire to remove this manual step in the plugin install/uninstall process, or if you just disagree with the proposed approach of achieving this through concatenating plugin JS into a single file. You can't have different web-pages with different plugins enabled on the native side, I don't think there would be much benefit to enable this use-case for just the HTML side. Do you have any example of when you'd want this? Votes are fine, but consensus is much better. I don't want to move forward with this until everyone is on board. > >> > >> This of course does not preclude use of this technique, however, I > >> feel very strongly that we should NOT be building this into our > >> framework, and forcing developers to use this approach. I think this > >> is definitely something that we should vote on before developing > >> further if the goal is inclusion in cordova. > >> > >> Cheers, > >> Jesse > >> > >> > >> On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux wrote: > >>> super interesting. I like where this is going. > >>> > >>> > >>> On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve > >>> wrote: > >>> > On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj wrote: > > > Dude: awesome! > > > > My answers in-line: > > > >> 2. Manually adding the
Re: Fast edit-refresh cycles
This also is feeding into some of the work we are doing with ripple. Ripple will serve up the app and host it kind of like how we do debug.phonegap.com for in browser testing. Sent from my iPhone On 2012-11-22, at 3:15 PM, Filip Maj wrote: > Agree with Jesse. > > Automatically adding the plugin's .js to html pages inside a www dir can > be done by the cordova-client tool anyways. > > Agree this should go to vote before we proceed. > > On 11/22/12 12:13 PM, "Jesse" wrote: > >> I think all the refresh stuff is super cool, I will share how I work, >> so you can get another perspective. >> 90% of my code is written on localhost, either running directly in a >> browser to work out UI stuff. >> When I need access to actual device APIs, I simply put a redirect in >> my index.html. >> This gets me through 99% of my work, after which I can fine tune an >> individual device or functional piece in XCode, Eclipse, Visual >> Studio, et al >> >> When it comes to inclusion of multiple script tags, I do not see this >> as a barrier at all. This is the way the internet has always worked, >> and it ain't broke. >> I like the explicit declaration of having a script tag, plus you can >> have multiple pages, with different plugin requirements. Adding an >> extra build step, + reinventing the internet inside our framework is >> madness in my opinion. >> >> This of course does not preclude use of this technique, however, I >> feel very strongly that we should NOT be building this into our >> framework, and forcing developers to use this approach. I think this >> is definitely something that we should vote on before developing >> further if the goal is inclusion in cordova. >> >> Cheers, >> Jesse >> >> >> On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux wrote: >>> super interesting. I like where this is going. >>> >>> >>> On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve >>> wrote: >>> On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj wrote: > Dude: awesome! > > My answers in-line: > >> 2. Manually adding the
Re: Fast edit-refresh cycles
Agree with Jesse. Automatically adding the plugin's .js to html pages inside a www dir can be done by the cordova-client tool anyways. Agree this should go to vote before we proceed. On 11/22/12 12:13 PM, "Jesse" wrote: >I think all the refresh stuff is super cool, I will share how I work, >so you can get another perspective. >90% of my code is written on localhost, either running directly in a >browser to work out UI stuff. >When I need access to actual device APIs, I simply put a redirect in >my index.html. >This gets me through 99% of my work, after which I can fine tune an >individual device or functional piece in XCode, Eclipse, Visual >Studio, et al > >When it comes to inclusion of multiple script tags, I do not see this >as a barrier at all. This is the way the internet has always worked, >and it ain't broke. >I like the explicit declaration of having a script tag, plus you can >have multiple pages, with different plugin requirements. Adding an >extra build step, + reinventing the internet inside our framework is >madness in my opinion. > >This of course does not preclude use of this technique, however, I >feel very strongly that we should NOT be building this into our >framework, and forcing developers to use this approach. I think this >is definitely something that we should vote on before developing >further if the goal is inclusion in cordova. > >Cheers, > Jesse > > >On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux wrote: >> super interesting. I like where this is going. >> >> >> On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve >>wrote: >> >>> On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj wrote: >>> >>> > Dude: awesome! >>> > >>> > My answers in-line: >>> > >>> > >2. Manually adding the
Re: Fast edit-refresh cycles
I think all the refresh stuff is super cool, I will share how I work, so you can get another perspective. 90% of my code is written on localhost, either running directly in a browser to work out UI stuff. When I need access to actual device APIs, I simply put a redirect in my index.html. This gets me through 99% of my work, after which I can fine tune an individual device or functional piece in XCode, Eclipse, Visual Studio, et al When it comes to inclusion of multiple script tags, I do not see this as a barrier at all. This is the way the internet has always worked, and it ain't broke. I like the explicit declaration of having a script tag, plus you can have multiple pages, with different plugin requirements. Adding an extra build step, + reinventing the internet inside our framework is madness in my opinion. This of course does not preclude use of this technique, however, I feel very strongly that we should NOT be building this into our framework, and forcing developers to use this approach. I think this is definitely something that we should vote on before developing further if the goal is inclusion in cordova. Cheers, Jesse On Thu, Nov 22, 2012 at 2:34 AM, Brian LeRoux wrote: > super interesting. I like where this is going. > > > On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve wrote: > >> On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj wrote: >> >> > Dude: awesome! >> > >> > My answers in-line: >> > >> > >2. Manually adding the
