cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Proposal for JS in Plugins
Date Thu, 07 Feb 2013 20:36:16 GMT
Good points Shaz and Andrew.

I'm up for trying it out (I think we're at a point where we should
prototype the approaches to get further).

The plugin.xml manifest lists web assets via <asset src="blah"
target="blah"> elements. Couple q's relating to this:
- I guess we use the target attribute on all of these <asset> elements to
determine what needs to be added via script tags to html files?
- <asset> elements can point to entire directories. So the tool would
search through all files listed under <assets> (recursing into
subdirectories if needed), and anything that is a .js file gets added as a
script tag to all .html files in the project?
- same for things like css files?

On 2/6/13 6:45 PM, "Shazron" <shazron@gmail.com> wrote:

>I'm looking at the task goal:
>"*Should be easy to install / remove plugins (no need to manually
>add/remove script tags)" and inserting the script tags seems the best
>solution, what alternative is there? If devs don't agree with this goal,
>then it should be removed, and we keep the hard to install way. I think
>this solution to the goal not a big deal since we are declaring the JS in
>plugin.xml, which is the indirect way of adding the script tag manually
>anyway. *
>*
>*
>*If we need to debug, perhaps an output of a tool that will "show" the
>final results of all this "magic" (ie what the script tags will look like
>in files that it is applied to) e.g.:*
>*
>*
>*index.html, spiffy.html, fab.html:*
>* <script src="bar.js"></script>*
>* <script src="foo.js"></script>*
>
>*
>*
>
>
>On Thu, Feb 7, 2013 at 1:01 AM, Andrew Grieve <agrieve@chromium.org>
>wrote:
>
>> For a project who's main language is JS, I'm a bit surprised that
>>injecting
>> a script tag through DOM manipulation would put us into the "magic"
>> category...
>>
>> Brian - Your sentiments about the development stack don't make sense to
>>me.
>> The development stack is *the* job of CLI. We are prescribing a way to
>>set
>> up your project so that it's easy to have an x-platform www directory,
>>and
>> writing tools to make it easy to add/remove plugins. Is not "the
>> development stack" *the* goal of CLI?
>>
>> This isn't a problem that we can "not solve". It's a problem that
>>exists,
>> and doing nothing *is a solution*. Here's the "do nothing" solution:
>> - Let plugins put their .js file anywhere within the www/ directory (and
>> hope that it doesn't clobber anything)
>> - Have them write documentation to instruct users that they must insert
>> their script tags into each of their .html files
>> - Hope that users notice the instructions, and that they are correct,
>>and
>> that they don't mess them up
>> - Hope that users can remember which JS files belong to what if they
>>ever
>> want to remove plugins
>>
>> Note that for our core plugins, we have 78 .js files just within
>> lib/common/plugin.
>>
>> A variation on "do nothing":
>> - Tell each plugin developer to come up with their own packaging system
>> - Tell them to check in a pre-packaged version with every commit (or
>>just
>> on releases)
>> - Tell them to write instructions for the manual steps involved in
>>adding /
>> removing their plugins.
>>
>> I don't accept that this isn't a problem. If there are actually better
>> alternatives, I'd like to hear what they are, and what the development
>> workflow looks like for both the plugin users as well as the plugin
>> developers.
>>
>>
>> Anis - What sort of needs / requirements are you thinking of that won't
>> work with the injecting script tags approach? Let's try and work through
>> them. The same argument could be used to shoot down the entire CLI
>> effort...
>>
>>
>> Andrew
>>
>>
>> On Wed, Feb 6, 2013 at 6:27 PM, Joe Bowser <bowserj@gmail.com> wrote:
>>
>> > I also disagree with automagically injecting the script tags.  If
>> > we're adding the script tags, we have the ability of adding the script
>> > tags wrong, and breaking people's apps with magic.  We have enough
>> > trouble directing our users to use Cordova/PhoneGap without us trying
>> > to make things more clever.
>> >
>> > On Wed, Feb 6, 2013 at 2:39 PM, Anis KADRI <anis.kadri@gmail.com>
>>wrote:
>> > > I don't think we should be automatically injecting javascript tags.
>> > > Instruct users to do so when they add a plugin by displaying the
>>tag.
>> > > Everyone has different needs/requirements.
>> > >
>> > > Also
>> > >
>> > > *"cordova plugin add file"
>> > > - Download plugin files to project/plugins
>> > > - Runs plugman to install native parts of the plugin.
>> > > - Plugman will copy JS files listed into
>> > > project/platforms/cordova-js/lib/...*
>> > > * *
>> > > *plugman supports installation by local-dir/git-repo/name. Names are
>> > > listed/stored on an outside source. So I believe this step should
>>just
>> > call
>> > > plugman with the name/git/local-dir. We've already agreed that all
>> > plugins
>> > > will have separate repositories, yes ?*
>> >
>>
>> Which step are you referring to? Could you maybe write out the version
>>of
>> how things work that you're suggesting?
>>
>>
>>
>> > > *
>> > > *
>> > > *I also agree that plugin.xml should support dependencies and that
>>we
>> > > should update the plugin spec. **I like the requires-plugin tag but
>>I
>> am
>> > > not sure I like that js-symbols tag in plugin.xml though. **I am
>> confused
>> > > about that "Exporting Module Symbols" section. An example would be
>> > > appreciated.*
>> >
>>
>> There's this example in the doc already:
>> *
>>
>> <js-symbols>
>>
>>    <defaults module=²cordova/plugin/file/requestFileSystem²
>> target=²requestFileSystem²>
>>
>>   <clobbers module=²cordova/plugin/network/connection²
>> target=²navigator.connection²>
>>
>>   <merges module=²cordova/plugin/file/FileEntry² target=²FileEntry²>
>> </js-symbols>*
>> *
>> *
>> And what symbol.js files look like is described in
>> https://issues.apache.org/jira/browse/CB-2227
>>
>> *Does this help? Is there something else you want an example of?*
>>
>> > *
>> > > *
>> > > *Anis*
>> > >
>> > >
>> > > On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson <
>> braden@chromium.org
>> > >wrote:
>> > >
>> > >> I think it's fine to have the default behavior be to inject script
>> tags.
>> > >> That will suffice for 90% of our users, probably more. If you fall
>> into
>> > the
>> > >> 10% that have some more complicated setup, we should provide a flag
>> like
>> > >> > cordova plugin add --no-inject-js myplugin
>> > >> that prevents us from doing it automatically, and you can do
>>whatever
>> > more
>> > >> complex step you need to do.
>> > >>
>> > >>
>> > >> Braden
>> > >>
>> > >>
>> > >> On Wed, Feb 6, 2013 at 3:37 PM, Andrew Grieve
>><agrieve@chromium.org>
>> > >> wrote:
>> > >>
>> > >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <fil@adobe.com>
wrote:
>> > >> >
>> > >> > >
>> > >> > >
>> > >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <agrieve@chromium.org>
>>wrote:
>> > >> > >
>> > >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <fil@adobe.com>
>>wrote:
>> > >> > > >
>> > >> > > >> I've added a few detail explanations to the document,
but
>>moved
>> > the
>> > >> > > >> discussion to the ML.
>> > >> > > >>
>> > >> > > >> ----
>> > >> > > >>
>> > >> > > >> > Should be easy to install / remove plugins
(no need to
>> manually
>> > >> > > >> >add/remove script tags)
>> > >> > > >>
>> > >> > > >>
>> > >> > > >> I think adding/removing script tags is the way to
go.
>> > Concatenating
>> > >> > all
>> > >> > > >> javascript relevant to your project (cordova.js
+ any
>>plugins
>> you
>> > >> add)
>> > >> > > >> makes it difficult to debug later on. WE'd have
to get
>>users to
>> > post
>> > >> > > >> entire contents of their cordova.js file to determine
what
>>was
>> > added
>> > >> > and
>> > >> > > >> what exists in there. With that in mind, I favor
the
>>packager
>> > >> > approach,
>> > >> > > >> which would require:
>> > >> > > >>
>> > >> > > >
>> > >> > > >Very good point about concat making it hard to track
bugs! I
>> > wonder if
>> > >> > > >there's a better way than requiring users to manually
add the
>> tags
>> > (we
>> > >> > > >don't require them to manually add native files to their
>>project
>> > >> files).
>> > >> > > >
>> > >> > > >One thought is to have cordova-packer output source-maps.
I
>>don't
>> > >> think
>> > >> > > >there's very good support for them in mobile browsers
yet,
>>but we
>> > >> could
>> > >> > > >use
>> > >> > > >them to manually map exception line numbers to file+line
>>numbers.
>> > >> > > >
>> > >> > > >Another idea is to use exec + special comment that is
used in
>>our
>> > >> > existing
>> > >> > > >pkg/debug/*.js files. I don't think support for this
is all
>>that
>> > great
>> > >> > > >either though.
>> > >> > > >
>> > >> > > >Another idea is to have cordova.js inject a script tag
for
>>each
>> > >> module.
>> > >> > > >This may have an adverse effect on start-up time, but
>>probably no
>> > >> worse
>> > >> > > >than if the user manually adds all of the script tags
>>separately.
>> > >> > Winner?
>> > >> > >
>> > >> > > I don't think the script tag is a giant issue, but I do think
>>it
>> is
>> > a
>> > >> > > slipper slope problem to try and solve. What if the user
has a
>> > >> multipage
>> > >> > > application? Do we then add script tags automatically to
all
>> pages?
>> > >> What
>> > >> > > if the user only uses the plugin on specific pages? Etc etc
>> > >> > >
>> > >> >
>> > >> > I'm suggesting that any page that include (manually) cordova.js
>>will
>> > have
>> > >> > it dynamically inject installed plugin JS files. Should work fine
>> in a
>> > >> > multi-page app. We don't currently disable plugins on a per-page
>> > basis.
>> > >> Is
>> > >> > this really an important use-case? If so, I'm sure we could
>>figure
>> out
>> > >> how
>> > >> > to not inject script tags for plugins you don't want.
>> > >> >
>> > >>
>> >
>>


Mime
View raw message