Andrew - what I was thinking was pretty much what Michal wrote below. Perhaps it was my interpretation of the original note but I thought defaults was to be applied only in the CLI workflow.
-James Jong On Sep 7, 2013, at 1:05 PM, Michal Mocny <mmo...@chromium.org> wrote: > With this proposal as it stands, I think that is already true (at least for > the initial contents, obviously user can make edits later). > > Ie, defaults.xml + app.xml = initial config.xml for both cases, which use > the same helloworld template's app.xml. > > If there are specific differences to the default values that we want, we > maybe will want to use a different app.xml for each, but defaults.xml > should be tied to a platform-version not to a workflow. > > -Michal > > > On Sat, Sep 7, 2013 at 7:56 AM, Andrew Grieve <agri...@chromium.org> wrote: > >> James - that's a nice goal, but I don't think it's feasible. Did you have a >> way to do that in mind? >> >> >> On Fri, Sep 6, 2013 at 10:31 PM, James Jong <wjamesj...@gmail.com> wrote: >> >>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>
