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 <[email protected]>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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 <[email protected]> > > 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 < > > [email protected] > > >> >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 < > [email protected]> > > >> >> wrote: > > >> >> > > >> >> > On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj <[email protected]> wrote: > > >> >> > > > >> >> > > > > >> >> > > > > >> >> > > On 2/6/13 11:51 AM, "Andrew Grieve" <[email protected]> > > wrote: > > >> >> > > > > >> >> > > >On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj <[email protected]> > > 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. > > >> >> > > > >> >> > > >> > > >
