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