cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Proposal for JS in Plugins
Date Tue, 19 Feb 2013 19:16:38 GMT
I think I like it! (But look forward to seeing it in a pull request.)


On Thu, Feb 14, 2013 at 10:31 AM, Braden Shepherdson <braden@chromium.org>wrote:

> So I've written up my plan for attacking this problem into a Google Doc
> I've shared for public comments:
>
>
> https://docs.google.com/document/d/1fhwnIZ5TqwklGx71pLmfSghysls1S4_5ktEsjA9ac5Y/edit?usp=sharing
>
> tl;dr version is that on cordova prepare (the new fast first part of
> cordova build, copies www) we read all installed plugins for new XML tags
> that define the JS modules and where they should be exposed on window, and
> inject code into cordova.js to load the modules, and do the
> clobbering/merging/executing as necessary. This is a relatively modest new
> feature for the CLI that doesn't require any refactoring, and should be
> fast enough to run on every prepare/build without significant slowdown.
>
> I'm working on a prototype of this approach in a fork of the CLI. If you
> spot any problems with the approach, please comment on the doc or in this
> thread.
>
> Braden
>
>
> On Fri, Feb 8, 2013 at 4:45 AM, Brian LeRoux <b@brian.io> wrote:
>
> > You know what. I'm super wrong. I was thinking in the context of a
> > native project and not a *cordova* project.
> >
> > The flaw in the thinking was that we were shipping only one file we
> > build leaving devs to include as they see fit. But whats really
> > happening is that we are generating a new file for every plugin
> > add/remove which will be different for each platform. If they move
> > that file around and include from a directory of their choosing we're
> > fucked.
> >
> > The difference here is the audience. A developer content to NOT use
> > our tools, and compose their own app for a single platform, say
> > Android, is going to have to figure out inclusion themselves. For us,
> > its a build time concern. Not magic.
> >
> > Consider: we are required to re-build every time a user adds/removes a
> > plugin. And if they move that generated file, again, we're fucked.
> > This is increasingly looking like a script inject....which we could
> > make configurable with config.xml so that it isn't too magical
> > feeling.
> >
> > We should talk about how the www install part works though. I wonder
> > if it would appropriate to propose a special folder in www for this
> > purpose. Like node_modules but without fugly underscores.
> >
> >
> > On Wed, Feb 6, 2013 at 4:01 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > > For a project who's main language is JS, I'm a bit surprised that
> > injecting
> > > a script tag through DOM manipulation would put us into the "magic"
> > > category...
> > >
> > > Brian - Your sentiments about the development stack don't make sense to
> > me.
> > > The development stack is *the* job of CLI. We are prescribing a way to
> > set
> > > up your project so that it's easy to have an x-platform www directory,
> > and
> > > writing tools to make it easy to add/remove plugins. Is not "the
> > > development stack" *the* goal of CLI?
> > >
> > > This isn't a problem that we can "not solve". It's a problem that
> exists,
> > > and doing nothing *is a solution*. Here's the "do nothing" solution:
> > > - Let plugins put their .js file anywhere within the www/ directory
> (and
> > > hope that it doesn't clobber anything)
> > > - Have them write documentation to instruct users that they must insert
> > > their script tags into each of their .html files
> > > - Hope that users notice the instructions, and that they are correct,
> and
> > > that they don't mess them up
> > > - Hope that users can remember which JS files belong to what if they
> ever
> > > want to remove plugins
> > >
> > > Note that for our core plugins, we have 78 .js files just within
> > > lib/common/plugin.
> > >
> > > A variation on "do nothing":
> > > - Tell each plugin developer to come up with their own packaging system
> > > - Tell them to check in a pre-packaged version with every commit (or
> just
> > > on releases)
> > > - Tell them to write instructions for the manual steps involved in
> > adding /
> > > removing their plugins.
> > >
> > > I don't accept that this isn't a problem. If there are actually better
> > > alternatives, I'd like to hear what they are, and what the development
> > > workflow looks like for both the plugin users as well as the plugin
> > > developers.
> > >
> > >
> > > Anis - What sort of needs / requirements are you thinking of that won't
> > > work with the injecting script tags approach? Let's try and work
> through
> > > them. The same argument could be used to shoot down the entire CLI
> > effort...
> > >
> > >
> > > Andrew
> > >
> > >
> > > On Wed, Feb 6, 2013 at 6:27 PM, Joe Bowser <bowserj@gmail.com> wrote:
> > >
> > >> I also disagree with automagically injecting the script tags.  If
> > >> we're adding the script tags, we have the ability of adding the script
> > >> tags wrong, and breaking people's apps with magic.  We have enough
> > >> trouble directing our users to use Cordova/PhoneGap without us trying
> > >> to make things more clever.
> > >>
> > >> On Wed, Feb 6, 2013 at 2:39 PM, Anis KADRI <anis.kadri@gmail.com>
> > wrote:
> > >> > I don't think we should be automatically injecting javascript tags.
> > >> > Instruct users to do so when they add a plugin by displaying the
> tag.
> > >> > Everyone has different needs/requirements.
> > >> >
> > >> > Also
> > >> >
> > >> > *"cordova plugin add file"
> > >> > - Download plugin files to project/plugins
> > >> > - Runs plugman to install native parts of the plugin.
> > >> > - Plugman will copy JS files listed into
> > >> > project/platforms/cordova-js/lib/...*
> > >> > * *
> > >> > *plugman supports installation by local-dir/git-repo/name. Names are
> > >> > listed/stored on an outside source. So I believe this step should
> just
> > >> call
> > >> > plugman with the name/git/local-dir. We've already agreed that all
> > >> plugins
> > >> > will have separate repositories, yes ?*
> > >>
> > >
> > > Which step are you referring to? Could you maybe write out the version
> of
> > > how things work that you're suggesting?
> > >
> > >
> > >
> > >> > *
> > >> > *
> > >> > *I also agree that plugin.xml should support dependencies and that
> we
> > >> > should update the plugin spec. **I like the requires-plugin tag but
> I
> > am
> > >> > not sure I like that js-symbols tag in plugin.xml though. **I am
> > confused
> > >> > about that "Exporting Module Symbols" section. An example would be
> > >> > appreciated.*
> > >>
> > >
> > > There's this example in the doc already:
> > > *
> > >
> > > <js-symbols>
> > >
> > >    <defaults module=”cordova/plugin/file/requestFileSystem”
> > > target=”requestFileSystem”>
> > >
> > >   <clobbers module=”cordova/plugin/network/connection”
> > > target=”navigator.connection”>
> > >
> > >   <merges module=”cordova/plugin/file/FileEntry” target=”FileEntry”>
> > > </js-symbols>*
> > > *
> > > *
> > > And what symbol.js files look like is described in
> > > https://issues.apache.org/jira/browse/CB-2227
> > >
> > > *Does this help? Is there something else you want an example of?*
> > >
> > >> *
> > >> > *
> > >> > *Anis*
> > >> >
> > >> >
> > >> > On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson <
> > braden@chromium.org
> > >> >wrote:
> > >> >
> > >> >> I think it's fine to have the default behavior be to inject script
> > tags.
> > >> >> That will suffice for 90% of our users, probably more. If you
fall
> > into
> > >> the
> > >> >> 10% that have some more complicated setup, we should provide a
flag
> > like
> > >> >> > cordova plugin add --no-inject-js myplugin
> > >> >> that prevents us from doing it automatically, and you can do
> whatever
> > >> more
> > >> >> complex step you need to do.
> > >> >>
> > >> >>
> > >> >> Braden
> > >> >>
> > >> >>
> > >> >> On Wed, Feb 6, 2013 at 3:37 PM, Andrew Grieve <
> agrieve@chromium.org>
> > >> >> wrote:
> > >> >>
> > >> >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fil@adobe.com>
wrote:
> > >> >> >
> > >> >> > >
> > >> >> > >
> > >> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <agrieve@chromium.org>
> > wrote:
> > >> >> > >
> > >> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fil@adobe.com>
> > wrote:
> > >> >> > > >
> > >> >> > > >> I've added a few detail explanations to the
document, but
> > moved
> > >> the
> > >> >> > > >> discussion to the ML.
> > >> >> > > >>
> > >> >> > > >> ----
> > >> >> > > >>
> > >> >> > > >> > Should be easy to install / remove plugins
(no need to
> > manually
> > >> >> > > >> >add/remove script tags)
> > >> >> > > >>
> > >> >> > > >>
> > >> >> > > >> I think adding/removing script tags is the
way to go.
> > >> Concatenating
> > >> >> > all
> > >> >> > > >> javascript relevant to your project (cordova.js
+ any
> plugins
> > you
> > >> >> add)
> > >> >> > > >> makes it difficult to debug later on. WE'd
have to get users
> > to
> > >> post
> > >> >> > > >> entire contents of their cordova.js file to
determine what
> was
> > >> added
> > >> >> > and
> > >> >> > > >> what exists in there. With that in mind, I
favor the
> packager
> > >> >> > approach,
> > >> >> > > >> which would require:
> > >> >> > > >>
> > >> >> > > >
> > >> >> > > >Very good point about concat making it hard to track
bugs! I
> > >> wonder if
> > >> >> > > >there's a better way than requiring users to manually
add the
> > tags
> > >> (we
> > >> >> > > >don't require them to manually add native files
to their
> project
> > >> >> files).
> > >> >> > > >
> > >> >> > > >One thought is to have cordova-packer output source-maps.
I
> > don't
> > >> >> think
> > >> >> > > >there's very good support for them in mobile browsers
yet, but
> > we
> > >> >> could
> > >> >> > > >use
> > >> >> > > >them to manually map exception line numbers to file+line
> > numbers.
> > >> >> > > >
> > >> >> > > >Another idea is to use exec + special comment that
is used in
> > our
> > >> >> > existing
> > >> >> > > >pkg/debug/*.js files. I don't think support for
this is all
> that
> > >> great
> > >> >> > > >either though.
> > >> >> > > >
> > >> >> > > >Another idea is to have cordova.js inject a script
tag for
> each
> > >> >> module.
> > >> >> > > >This may have an adverse effect on start-up time,
but probably
> > no
> > >> >> worse
> > >> >> > > >than if the user manually adds all of the script
tags
> > separately.
> > >> >> > Winner?
> > >> >> > >
> > >> >> > > I don't think the script tag is a giant issue, but I
do think
> it
> > is
> > >> a
> > >> >> > > slipper slope problem to try and solve. What if the
user has a
> > >> >> multipage
> > >> >> > > application? Do we then add script tags automatically
to all
> > pages?
> > >> >> What
> > >> >> > > if the user only uses the plugin on specific pages?
Etc etc
> > >> >> > >
> > >> >> >
> > >> >> > I'm suggesting that any page that include (manually) cordova.js
> > will
> > >> have
> > >> >> > it dynamically inject installed plugin JS files. Should work
fine
> > in a
> > >> >> > multi-page app. We don't currently disable plugins on a per-page
> > >> basis.
> > >> >> Is
> > >> >> > this really an important use-case? If so, I'm sure we could
> figure
> > out
> > >> >> how
> > >> >> > to not inject script tags for plugins you don't want.
> > >> >> >
> > >> >>
> > >>
> >
>

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