Proposal for JS in Plugins

[Andrew Grieve <ag...@chromium.org>]

I've taken the result of the previous thread of
CB-2214<https://issues.apache.org/jira/browse/CB-2214>,
and turned it into a proposal doc:

https://docs.google.com/document/d/1Evzu8qliwxBWGj9-U8ea1rvrbd-jokmN4Dti8AGAXdU/edit#

Please feel free to add comments / edit the proposals.

Re: Proposal for JS in Plugins

[Andrew Grieve <ag...@chromium.org>]

Maybe another motivating use-case is when plugin authors add new .js files
(or remove them, or rename them). Then we'd need to tell each app to update
their html files.


On Wed, Feb 6, 2013 at 4:01 PM, Michal Mocny <mm...@chromium.org> wrote:

> Right now you insert a single cordova.js for bridge and all core plugins.
>  If we do *not* inject scripts, then all users will need to update all apps
> to include potentially a lot of script tags, right?
>
>
> On Wed, Feb 6, 2013 at 3:52 PM, Jesse <pu...@gmail.com> wrote:
>
> > I am leaning towards Fil's points.
> > The advantage of script tags is everyone understands how they work.  Only
> > use magic when magic is required.
> >
> >
> >
> > 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 <ag...@chromium.org>
> > > wrote:
> > >
> > > > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> > > >
> > > > >
> > > > >
> > > > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > > > >
> > > > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> > > >
> > >
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>

Re: Proposal for JS in Plugins

[Michal Mocny <mm...@chromium.org>]

Right now you insert a single cordova.js for bridge and all core plugins.
 If we do *not* inject scripts, then all users will need to update all apps
to include potentially a lot of script tags, right?


On Wed, Feb 6, 2013 at 3:52 PM, Jesse <pu...@gmail.com> wrote:

> I am leaning towards Fil's points.
> The advantage of script tags is everyone understands how they work.  Only
> use magic when magic is required.
>
>
>
> 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 <ag...@chromium.org>
> > wrote:
> >
> > > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > > >
> > > >
> > > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > > >
> > > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> > >
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Proposal for JS in Plugins

[Michal Mocny <mm...@chromium.org>]

Then, if we don't inject the js automatically, how does a developer get the
list of scripts they need to include?

Will the docs say to include everything from
*project/platforms/cordova-js/lib/...
dir, or should cordova-cli have a list-scripts command?*
*
*
*-Michal*


On Wed, Feb 6, 2013 at 4:07 PM, Brian LeRoux <b...@brian.io> wrote:

> I am not in favor of prescribing any part of the development stack.
> Some ppl like requirejs. Etc. This is really not a problem we need to
> add to the list of things we need to solve!
>
>
> (More detailed feedback on the way.)
>
> On Wed, Feb 6, 2013 at 12:52 PM, Jesse <pu...@gmail.com> wrote:
> > I am leaning towards Fil's points.
> > The advantage of script tags is everyone understands how they work.  Only
> > use magic when magic is required.
> >
> >
> >
> > 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 <ag...@chromium.org>
> >> wrote:
> >>
> >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >
> >> > >
> >> > >
> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >> > >
> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> >> >
> >>
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
>

Re: Proposal for JS in Plugins

[Brian LeRoux <b...@brian.io>]

I am not in favor of prescribing any part of the development stack.
Some ppl like requirejs. Etc. This is really not a problem we need to
add to the list of things we need to solve!


(More detailed feedback on the way.)

On Wed, Feb 6, 2013 at 12:52 PM, Jesse <pu...@gmail.com> wrote:
> I am leaning towards Fil's points.
> The advantage of script tags is everyone understands how they work.  Only
> use magic when magic is required.
>
>
>
> On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson <br...@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 <ag...@chromium.org>
>> wrote:
>>
>> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> > >
>> > >
>> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> > >
>> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
>> >
>>
>
>
>
> --
> @purplecabbage
> risingj.com

Re: Proposal for JS in Plugins

[Jesse <pu...@gmail.com>]

I am leaning towards Fil's points.
The advantage of script tags is everyone understands how they work.  Only
use magic when magic is required.



On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson <br...@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 <ag...@chromium.org>
> wrote:
>
> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> > >
> > >
> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> >
>



-- 
@purplecabbage
risingj.com

Re: Proposal for JS in Plugins

[Brian LeRoux <b...@brian.io>]

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 <br...@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 <ag...@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 <bo...@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 <an...@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 <fi...@adobe.com> wrote:
> > >> >> >
> > >> >> > >
> > >> >> > >
> > >> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org>
> > wrote:
> > >> >> > >
> > >> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> > >> >> >
> > >> >>
> > >>
> >
>

Re: Proposal for JS in Plugins

[Braden Shepherdson <br...@chromium.org>]

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 <ag...@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 <bo...@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 <an...@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 <ag...@chromium.org>
> >> >> wrote:
> >> >>
> >> >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >> >
> >> >> > >
> >> >> > >
> >> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org>
> wrote:
> >> >> > >
> >> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> >> >> >
> >> >>
> >>
>

Re: Proposal for JS in Plugins

[Brian LeRoux <b...@brian.io>]

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 <ag...@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 <bo...@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 <an...@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 <ag...@chromium.org>
>> >> wrote:
>> >>
>> >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> >
>> >> > >
>> >> > >
>> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >> > >
>> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
>> >> >
>> >>
>>

Re: Proposal for JS in Plugins

[Filip Maj <fi...@adobe.com>]

I don't think this feature would take that ability away..

If using the cordova-cli tools as an example of what happens, you have a
structure like:

Project
 |-www  <--------- your app assets
 `-platforms  <--- android, iOS, etc projects

Anything you put into www will be copied into the platforms/<platform>/www
directory before running any build, emulate, run, etc. command.

On 2/7/13 1:23 PM, "Andrew Grieve" <ag...@chromium.org> wrote:

>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 <fi...@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" <sh...@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 <ag...@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 <bo...@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 <an...@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
>> >><ag...@chromium.org>
>> >> > >> wrote:
>> >> > >>
>> >> > >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com>
>>wrote:
>> >> > >> >
>> >> > >> > >
>> >> > >> > >
>> >> > >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org>
>> >>wrote:
>> >> > >> > >
>> >> > >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
>> >> > >> >
>> >> > >>
>> >> >
>> >>
>>
>>

Re: Proposal for JS in Plugins

[Andrew Grieve <ag...@chromium.org>]

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 <fi...@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" <sh...@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 <ag...@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 <bo...@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 <an...@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
> >><ag...@chromium.org>
> >> > >> wrote:
> >> > >>
> >> > >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> >> > >> >
> >> > >> > >
> >> > >> > >
> >> > >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org>
> >>wrote:
> >> > >> > >
> >> > >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> >> > >> >
> >> > >>
> >> >
> >>
>
>

Re: Proposal for JS in Plugins

[Filip Maj <fi...@adobe.com>]

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" <sh...@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 <ag...@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 <bo...@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 <an...@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
>><ag...@chromium.org>
>> > >> wrote:
>> > >>
>> > >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
>> > >> >
>> > >> > >
>> > >> > >
>> > >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org>
>>wrote:
>> > >> > >
>> > >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
>> > >> >
>> > >>
>> >
>>

Re: Proposal for JS in Plugins

[Shazron <sh...@gmail.com>]

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 <ag...@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 <bo...@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 <an...@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 <ag...@chromium.org>
> > >> wrote:
> > >>
> > >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> > >> >
> > >> > >
> > >> > >
> > >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >> > >
> > >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> > >> >
> > >>
> >
>

Re: Proposal for JS in Plugins

[Andrew Grieve <ag...@chromium.org>]

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 <bo...@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 <an...@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 <ag...@chromium.org>
> >> wrote:
> >>
> >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> >> >
> >> > >
> >> > >
> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >> > >
> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> >> >
> >>
>

Re: Proposal for JS in Plugins

[Joe Bowser <bo...@gmail.com>]

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 <an...@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 ?*
> *
> *
> *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.*
> *
> *
> *Anis*
>
>
> On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson <br...@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 <ag...@chromium.org>
>> wrote:
>>
>> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> > >
>> > >
>> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> > >
>> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
>> >
>>

Re: Proposal for JS in Plugins

[Anis KADRI <an...@gmail.com>]

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 ?*
*
*
*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.*
*
*
*Anis*


On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson <br...@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 <ag...@chromium.org>
> wrote:
>
> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> > >
> > >
> > > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> > >
> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
> >
>

Re: Proposal for JS in Plugins

[Braden Shepherdson <br...@chromium.org>]

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 <ag...@chromium.org> wrote:

> On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:
>
> >
> >
> > On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >
> > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.
>

Re: Proposal for JS in Plugins

[Andrew Grieve <ag...@chromium.org>]

On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fi...@adobe.com> wrote:

>
>
> On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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.

Re: Proposal for JS in Plugins

[Filip Maj <fi...@adobe.com>]

On 2/6/13 11:51 AM, "Andrew Grieve" <ag...@chromium.org> wrote:

>On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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

Re: Proposal for JS in Plugins

[Andrew Grieve <ag...@chromium.org>]

On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fi...@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?



>
> > declaring JS symbol mapping and JS dependencies in plugin.xml
>
> +1 to that bit. We should add it to the wiki page on plugin design if
> everyone agrees on it.
>
> On 2/6/13 10:46 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
> >Bump
> >
> >
> >On Mon, Feb 4, 2013 at 4:47 PM, Andrew Grieve <ag...@chromium.org>
> >wrote:
> >
> >> I've taken the result of the previous thread of
> >>CB-2214<https://issues.apache.org/jira/browse/CB-2214>,
> >> and turned it into a proposal doc:
> >>
> >>
> >>
> >>
> https://docs.google.com/document/d/1Evzu8qliwxBWGj9-U8ea1rvrbd-jokmN4Dti8
> >>AGAXdU/edit#
> >>
> >> Please feel free to add comments / edit the proposals.
> >>
>
>

Re: Proposal for JS in Plugins

[Filip Maj <fi...@adobe.com>]

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:

> declaring JS symbol mapping and JS dependencies in plugin.xml

+1 to that bit. We should add it to the wiki page on plugin design if
everyone agrees on it.

On 2/6/13 10:46 AM, "Andrew Grieve" <ag...@chromium.org> wrote:

>Bump
>
>
>On Mon, Feb 4, 2013 at 4:47 PM, Andrew Grieve <ag...@chromium.org>
>wrote:
>
>> I've taken the result of the previous thread of
>>CB-2214<https://issues.apache.org/jira/browse/CB-2214>,
>> and turned it into a proposal doc:
>>
>>
>> 
>>https://docs.google.com/document/d/1Evzu8qliwxBWGj9-U8ea1rvrbd-jokmN4Dti8
>>AGAXdU/edit#
>>
>> Please feel free to add comments / edit the proposals.
>>

Re: Proposal for JS in Plugins

[Andrew Grieve <ag...@chromium.org>]

Bump


On Mon, Feb 4, 2013 at 4:47 PM, Andrew Grieve <ag...@chromium.org> wrote:

> I've taken the result of the previous thread of CB-2214<https://issues.apache.org/jira/browse/CB-2214>,
> and turned it into a proposal doc:
>
>
> https://docs.google.com/document/d/1Evzu8qliwxBWGj9-U8ea1rvrbd-jokmN4Dti8AGAXdU/edit#
>
> Please feel free to add comments / edit the proposals.
>