cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Proposal for JS in Plugins
Date Thu, 07 Feb 2013 21:23:13 GMT
I don't think we'd want to take away the ability to just copy in a file to
the www/ directory. I think it might be better for them to opt-in the files
they want to have included in this auto-inject system. Prototyping SGTM.




On Thu, Feb 7, 2013 at 3:36 PM, Filip Maj <fil@adobe.com> wrote:

> Good points Shaz and Andrew.
>
> I'm up for trying it out (I think we're at a point where we should
> prototype the approaches to get further).
>
> The plugin.xml manifest lists web assets via <asset src="blah"
> target="blah"> elements. Couple q's relating to this:
> - I guess we use the target attribute on all of these <asset> elements to
> determine what needs to be added via script tags to html files?
> - <asset> elements can point to entire directories. So the tool would
> search through all files listed under <assets> (recursing into
> subdirectories if needed), and anything that is a .js file gets added as a
> script tag to all .html files in the project?
> - same for things like css files?
>
> On 2/6/13 6:45 PM, "Shazron" <shazron@gmail.com> wrote:
>
> >I'm looking at the task goal:
> >"*Should be easy to install / remove plugins (no need to manually
> >add/remove script tags)" and inserting the script tags seems the best
> >solution, what alternative is there? If devs don't agree with this goal,
> >then it should be removed, and we keep the hard to install way. I think
> >this solution to the goal not a big deal since we are declaring the JS in
> >plugin.xml, which is the indirect way of adding the script tag manually
> >anyway. *
> >*
> >*
> >*If we need to debug, perhaps an output of a tool that will "show" the
> >final results of all this "magic" (ie what the script tags will look like
> >in files that it is applied to) e.g.:*
> >*
> >*
> >*index.html, spiffy.html, fab.html:*
> >* <script src="bar.js"></script>*
> >* <script src="foo.js"></script>*
> >
> >*
> >*
> >
> >
> >On Thu, Feb 7, 2013 at 1:01 AM, 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