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 > > >
