I thought we were adding support for the last bit (ie, app generic not platform specific preferences) to "app.xml" which the helloworld template should ship with and bin/create should apply.
-Michal On Fri, Sep 6, 2013 at 10:52 AM, Ian Clelland <iclell...@chromium.org>wrote: > The template version needs to be a complete config file for the sample app, > though. You should be able to run bin/create and then build the Hello, > Cordova app immediately. > > defaults.xml is supposed to be stripped right down to just the > platform-specific options which, in theory, shouldn't need to be specified > by every app. > > At least that's how it works in my head :) The distinction may be less > important than I'm imagining. > > Ian > > > On Fri, Sep 6, 2013 at 9:08 AM, Michal Mocny <mmo...@chromium.org> wrote: > > > If the content or format of defaults.xml and the initial config.xml will > be > > different then we should ship both -- but I don't think they will be, so > I > > think we just ship the template with a defaults file. > > > > -Michal > > > > > > On Thu, Sep 5, 2013 at 11:19 PM, Ian Clelland <iclell...@chromium.org > > >wrote: > > > > > On Thu, Sep 5, 2013 at 5:16 PM, James Jong <wjamesj...@gmail.com> > wrote: > > > > > > > defaults.xml - Is that only used by CLI? And not used by bin/create > > > > scripts? > > > > It was bit unclear to me from the description since both were > mentioned > > > > regarding the 2 xml files. > > > > > > > > > > Yes, that's the idea. If you're using the bin/create scripts, then > there > > is > > > a complete "config.xml" file in the template that will be used for your > > new > > > app. This is for strict backwards compatibility with anyone's workflow > > that > > > doesn't currently include CLI. > > > > > > If you are using CLI, then we will construct a new config.xml file for > > you > > > instead, from three sources: defaults.xml, which specifies all of the > > > platform defaults; the various plugin.xml files, and your app's > > config.xml > > > file. The end-result should be the same, but you have a clear place to > > > override the defaults for your app that lives outside of your platforms > > > directory, and the cordova team has a clear place to set those same > > > defaults. > > > > > > Ian > > > > > > > > > > > > > > The new CLI prepare flow makes sense to me. > > > > > > > > -James Jong > > > > > > > > On Sep 5, 2013, at 2:21 PM, Michal Mocny <mmo...@chromium.org> > wrote: > > > > > > > > > We briefly discussed JSON and the two thoughts were: > > > > > > > > > > (1) We like it, but really what does it buy us? > > > > > (2) This change is at the moment 100% compatible with all current > > > > workflows > > > > > (including upgrades from 3.0->3.1), and we think that's important > for > > > > > headache-less adoption. JSON would obviously not be. > > > > > > > > > > > > > > > Regarding where to store the defaults, we had thought it would be a > > > file > > > > > bundled with the platform, perhaps in bin/templates? > > > > > > > > > > -Michal > > > > > > > > > > > > > > > On Thu, Sep 5, 2013 at 12:38 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > > > > > >> The logic flow is much safer in this method. Where do you think > > > > default.xml > > > > >> should live? (Maybe it doesn't have to exist and defaults can just > > be > > > > vars > > > > >> in the logic that does the processing?) > > > > >> > > > > >> Is this our opportunity to move to JSON? > > > > >> > > > > >> > > > > >> On Thu, Sep 5, 2013 at 8:21 AM, Braden Shepherdson < > > > bra...@chromium.org > > > > >>> wrote: > > > > >> > > > > >>> config.xml as a build artifact for less suffering and easier > > upgrades > > > > >>> Terminology > > > > >>> > > > > >>> - > > > > >>> > > > > >>> “platform config.xml” refers to the platform-specific > config.xml > > > > >> files, > > > > >>> eg. platforms/android/res/xml/config.xml. This is the final > file > > > read > > > > >> by > > > > >>> Cordova at runtime. > > > > >>> - > > > > >>> > > > > >>> “app config.xml” refers to the top-level config.xml found in > > > > >>> www/config.xml. > > > > >>> > > > > >>> Why the current situation is suffering > > > > >>> > > > > >>> - > > > > >>> > > > > >>> Chiefly, the platforms/foo/.../config.xml files are both the > > input > > > > and > > > > >>> output of munging by Plugman and the user. This sucks. It makes > > > > >>> automatic upgrades difficult because everybody has a customized > > > > >>> config.xml > > > > >>> file in their platforms. It also makes plugin rm harder and > less > > > > >> robust > > > > >>> in > > > > >>> CLI than it needs to be. > > > > >>> - > > > > >>> > > > > >>> Currently only some tags in the app config.xml are actually > > > honoured. > > > > >>> Others are ignored, and this has tripped up our users. > > > > >>> > > > > >>> > > > > >>> Goals > > > > >>> > > > > >>> - > > > > >>> > > > > >>> bin/create workflow is unchanged. > > > > >>> - > > > > >>> > > > > >>> Final content of the platform config.xml file is unchanged, > > though > > > > the > > > > >>> method of building it in the CLI can change. > > > > >>> - > > > > >>> > > > > >>> CLI workflow is unchanged, in terms of what a user types. > > > > >>> - > > > > >>> > > > > >>> platform config.xml stops being both input and output under > CLI. > > > Less > > > > >>> munging, and easier upgrades. In short, platform config.xml > files > > > > >> become > > > > >>> build artifacts. > > > > >>> > > > > >>> What we propose to do about it > > > > >>> > > > > >>> - > > > > >>> > > > > >>> First, adjust the platform template (used by bin/create) to > > contain > > > > >> two > > > > >>> files: > > > > >>> - > > > > >>> > > > > >>> defaults.xml, which is versioned, immutable, and tucked away > > > > >>> somewhere (only CLI accesses it) and contains only the > > > > >>> Cordova-specified > > > > >>> platform defaults, such as the preferences, any default > > > > >>> whitelist entries, > > > > >>> etc. It does NOT contain any <author>, <name> or other such > > > tags. > > > > >>> - > > > > >>> > > > > >>> platform config.xml, which is the same as it currently is, a > > > > >> complete > > > > >>> config.xml for the HelloWorld app. This means behavior is > > > > unchanged > > > > >>> for people who are not using CLI. Plugman still munges this > > file > > > > >> and > > > > >>> outputs back to it, same as now. > > > > >>> - > > > > >>> > > > > >>> Second, adjust the CLI’s cordova create template so that its > > > > top-level > > > > >>> app config.xml contains <name>, <author>, <content>, etc. - > tags > > > the > > > > >>> user is likely to edit. > > > > >>> - > > > > >>> > > > > >>> Third, modify the CLI so that the new cordova prepare flow is: > > > > >>> - > > > > >>> > > > > >>> Delete the old platform config.xml. > > > > >>> - > > > > >>> > > > > >>> Copy the defaults.xml to config.xml. > > > > >>> - > > > > >>> > > > > >>> Re-run the Plugman config munging for every plugin, > modifying > > > the > > > > >>> fresh platform config.xml. (The order here is deliberately > > > > >> undefined; > > > > >>> plugins should already not be relying on this.) > > > > >>> - > > > > >>> > > > > >>> Run the config munging for the app’s config.xml as well. > > > > >>> - > > > > >>> > > > > >>> This results in a freshly built, build-artifact platform > > > > >> config.xml. > > > > >>> Users should not be editing it; their top-level app > config.xml > > > > >>> has the last > > > > >>> word and will override any settings the defaults or plugins > > > might > > > > >>> make. > > > > >>> - > > > > >>> > > > > >>> Note that this means we shouldn’t be needlessly setting > > > > defaults > > > > >>> in the app config.xml, since this might prevent plugins > > from > > > > >>> changing > > > > >>> things that need changing. > > > > >>> - > > > > >>> > > > > >>> Fourth, extend the app config.xml format so that it can have > > > > >>> <platform>tags, like a plugin.xml. > > > > >>> - > > > > >>> > > > > >>> Into this it can put platform-specific things like > > > splashscreens, > > > > >>> preferences and other things, rather than mixing these > > together > > > in > > > > >>> the > > > > >>> config. > > > > >>> - > > > > >>> > > > > >>> In particular, it can have <config-file> tags in the usual > > > format > > > > >>> > > > > >> > > > > > > > > > > > > > >
