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. > >> > >> > > >> > >> > >> > > >> > >
