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