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:20:58 GMT
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 <braden@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 <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 <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