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