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