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" <agri...@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 <f...@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" <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. >> >> > >> > >> >> > >> >> >> > >> >> >> >>
