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 <b...@brian.io> 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 <f...@adobe.com> 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" <purplecabb...@gmail.com> 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 <b...@brian.io> wrote: > > > >>> super interesting. I like where this is going. > > > >>> > > > >>> > > > >>> On Thu, Nov 22, 2012 at 3:42 AM, Andrew Grieve < > agri...@chromium.org > > > > > > >>> wrote: > > > >>> > > > >>>> On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj <f...@adobe.com> wrote: > > > >>>> > > > >>>>> Dude: awesome! > > > >>>>> > > > >>>>> My answers in-line: > > > >>>>> > > > >>>>>> 2. Manually adding the <script> tags to include every new plugin > > is > > > >>>> really > > > >>>>>> lame. I propose a unified file, plugins.js or similar, that's > > always > > > >>>>>> included in the index.html. Every time you add or remove a > plugin, > > > >>>> the > > > >>>>>> Javascript files for all the plugins are concatenated into this > > > >>>> file. > > > >>>>>> There > > > >>>>>> are likely some problems with this approach. Inserting/removing > > the > > > >>>>>> <script> tags from the index page is also an option, though it > > > >>>> requires > > > >>>>>> more clever scripts. > > > >>>>> > > > >>>>> Can you elaborate more on this? I don't understand. > > > >>>> > > > >>>> Here's the motivating example to explain this: > > > >>>> - Our goal for 3.0 is to have cordova be just the bridge, and to > > have > > > >>>> all > > > >>>> core plugins in separate repos > > > >>>> - Right now, when you pluginstall a plugin, you need to manually > > edit > > > >>>> your > > > >>>> .html to add the .js of the plugin in a <script> tag. > > > >>>> - This will be quite annoying to have to add ~10 <script> tags, > (one > > > >>>> for > > > >>>> each core plugin, plus one for each non-core plugin you have) > > > >>>> > > > >>>> Here's Braden's idea explained a bit more: > > > >>>> - Have a plugin.js file in addition to the cordova.js file > > > >>>> - cordova.js to have the platform's bridge & init code > > > >>>> - plugins.js to contain the concatenation of all plugin .js files > > > >>>> - plugins.js to be regenerated whenever a plugin is added / > removed > > > >>>> - Apps will need to add both .js files to their html, but not need > > to > > > >>>> add a > > > >>>> <script> for every plugin separately. > > > >>>> > > > >>>> > > > >>>> > > > >>>>> > > > >>>>>> 3. Setting the start page manually on every platform sucks. I > > think > > > >>>> this > > > >>>>>> should be a value in config.xml that gets set on cordova build. > > > >>>> Obviously > > > >>>>>> that requires 1. to be fixed, but we'll get there soon. > > > >>>>> > > > >>>>> Yes, there is config.xml prior art for this: > > > >>>>> > > http://www.w3.org/TR/widgets/#the-content-element-and-its-attributes > > > >>>>> > > > >>>>> We should file issues to add support for this. > > > >>>>> > > > >>>>> Thanks for forking + contributing to cordova-client, stoked to > see > > > >>>> more > > > >>>>> contributors in there! Related: once we migrate to our new git > > repos > > > >>>> we > > > >>>>> should get a new one set up for cordova-client. > > > >> > > > >> > > > >> > > > >> -- > > > >> @purplecabbage > > > >> risingj.com > > > > > > > > > >
