I would like to see the defaults be applied in all cases. For consistency, less confusion, and easier documentation. If we add or change the defaults in a release, both workflows should get it. In my mind, the CLI platform config.xml should be equivalent to the bin/create one.
-James Jong On Sep 6, 2013, at 11:06 AM, Michal Mocny <mmo...@chromium.org> wrote: > 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 >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>
