Nice! I will check it out later today. On Thursday, December 5, 2013, Michal Mocny wrote:
> Alright, I've landed a defaults.xml for ios and android and closed the long > standing bugs for this. > > Aside from removing the <access> tag, I also removed the settings which are > overwritten by the app-level config anyway, such as app name, description, > <content> tag, etc. Please take a look if you have any concerns. I did > leave the default platform preferences/features in there, because those can > be overridden in the app config and many really are platform specific. > > Tested using both the CLI and bin/create workflows to make sure both still > work and do what we intent. > > Now, when a CLI user makes changes to the app config to remove <content> or > <access> tags, the final platform config actually reflects those changes. > Win. > > -Michal > > > On Wed, Dec 4, 2013 at 2:31 PM, Tommy-Carlos Williams > <to...@devgeeks.org<javascript:;> > >wrote: > > > +1 > > > > This is all sounding great and no matter how much I love the CLI, > > supporting both workflows is important. > > > > > > > > > > On 5 Dec 2013, at 6:13 am, Michal Mocny <mmo...@chromium.org> wrote: > > > > > Yes, there is no need to change the tools, which is why I like this > > > approach. I forgot to mention that part :P > > > > > > I did not think we previously discussed supplying both config files > with > > > different default settings. I had previously imagined we would ship > > > platforms with only one defaults file (defaults.xml/config.xml > whichever > > > name) that was consumed by both flows. The function of a defaults.xml > > was > > > as an implementation detail of CLI to help us treat config.xml as a > build > > > artifact. Now I am proposing using it as a first class config file > that > > > gets maintained along with config.xml in platform releases. > > > > > > -Michal > > > > > > > > > On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson <bra...@google.com > > >wrote: > > > > > >> It's possible I'm misunderstanding something here, but the flow you > > >> described here is exactly the one we intended when designing how > > >> details.xml was going to work. Platforms ship both files, cli uses > > >> defaults.xml where available, and config.xml where not. Platform > scripts > > >> use config.xml always. > > >> > > >> I don't think any (many?) Changes to the tools will be necessary to > > support > > >> this. > > >> > > >> Braden > > >> On Dec 4, 2013 8:25 AM, "Michal Mocny" <mmo...@chromium.org> wrote: > > >> > > >>> Alright, Andrew and I discussed this and think we have a resolution > > that > > >>> works with all the use cases (yay for options). > > >>> > > >>> TLDR; I think we already (accidentally?) support using a different > > >> default > > >>> platform config file for each of our two workflows. This means we > can > > >> have > > >>> the <access origin="*"> tag live inside the platform config for > > >>> platform-centric workflow, and inside the app config for app-centric > > >>> workflow. This means users less surprise for end users, and > downstream > > >>> distributions can more sensibly override these types of defaults > should > > >>> they chose to. > > >>> > > >>> ---- > > >>> > > >>> Most platforms don't ship with a defaults.xml file yet (except for > BB; > > >>> because Jeff did this work, he followed through for that platform). > > >> There > > >>> are open bugs to add these (ie, CB-5047). > > >>> > > >>> Jeff also added a nice fallback to the CLI: if there does not exist a > > >>> defaults.xml when running "prepare", backup the initial config.xml > to a > > >>> defaults.xml file before we go messing everything up with plugin / > app > > >>> settings. Effectively the config.xml that ships with platforms is > the > > >>> defaults.xml for platforms that don't have one explicitly added. > This > > >> is a > > >>> great default. > > >>> > > >>> However, if there actually were a defaults.xml, the CLI would consume > > >> that > > >>> for its initial input in the prepare process, and completely ignore > the > > >>> platform config.xml. The bin/create script would completely ignore > the > > >>> defaults.xml file and use only the config.xml file. > > >>> > > >>> So, if we shipped both a config.xml *and* defaults.xml, we could > choose > > >>> which settings to set for each workflow. I don't actually think the > > >>> settings should generally differ, and its mildly annoying that we > would > > >>> have mostly duplicated files, but it means we can move such > "optional" > > >>> settings as <access> or <dependency> etc out of the platform config, > > and > > >>> into the default app config which lives in cordova-cli, since that is
