cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Fast edit-refresh cycles
Date Fri, 23 Nov 2012 15:02:12 GMT
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 <agrieve@chromium.org> wrote:

> On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner <gtanner@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 <fil@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" <purplecabbage@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 <agrieve@chromium.org
> >
> > >>> wrote:
> > >>>
> > >>>> On Wed, Nov 21, 2012 at 6:37 PM, Filip Maj <fil@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message