Indeed the platform sections that you both mentioned are great in the shared config.
I'm still seeing them duplicated in the config file after preparing though. So I guess I'll submit a bug report... Thanks, Matt On 4/14/14 10:19 AM, "Ian Clelland" <iclell...@chromium.org> wrote: >On Mon, Apr 14, 2014 at 9:57 AM, Matt Scafidi-McGuire < >matt.scafidi-mcgu...@dealer.com> wrote: > >> We're using cordova to build for iOS & Android and we struggle with a >>few >> issues with the defaults/config mechanisms for plugin preferences. >>Perhaps >> we just don't understand how it's meant to be used or perhaps we've >> uncovered a bug. These first two issues lead us to the problem I'm >>writing >> about. >> >> We can't put custom preferences in the shared config file that have a >>copy >> in the defaults.xml, because both end up in the generated config file. >>It >> seems like preferences shouldn't be repeated in the generated config >>file >> whether they contradict each other or not. It seems like any >>preference or >> attribute in the shared config should override one found in the >> defaults.xml. >> > >Yes, anything in your config.xml should override a similar preference in >defaults.xml. defaults.xml is a file that we ship with the platforms to >encapsulate the default Cordova behaviour for each platform, rather than >putting all of those defaults in code. It isn't meant to be edited by end >users. > >If this is still happening (duplicate preferences ending up in the final >config), it's because we're doing some very naive XML parsing, both on the >Cordova CLI side and at run-time. At run-time, the last entry that is >found >in the application's config.xml should be the one that is used. > > >> We don't want to put platform-specific preferences in the shared >> config.xml file because it'll end up in the config files for both >>platforms. > > > >It is currently possible to put platform-specific preferences in the >shared >config.xml file. Just like in a plugin.xml file, you can have <platform> >sections, and tags within those sections will only be parsed for that >platform. > > > >> Although we could leave them in there cluttering the final generated >> config file, we'd rather not. The fact that we already have to edit the >> defaults.xml files to solve the previous problem led us to this >>solution. >> We put all shared values in the shared config.xml and any platform >> specific settings in the respective defaults.xml. >> >> That worked well for us until we upgraded. It seems as part of the >> upgrade, the defaults.xml files were all cleared. After uninstalling & >> reinstalling each plugin (no plugins update?), the defaults.xml files >>were >> full of defaults and our custom settings were all gone. >> >> So what are we missing? Is there any documentation on the most >>effective >> use of these files? >> >> If we leave custom preferences in the shared config.xml, how do we >>prevent >> duplication/competition with the copies in defaults.xml? >> >> Is there yet another place for platform specific settings? Is there >> anyway to prevent nuking the defaults.xml when upgrading? >> > >No, defaults.xml should probably be considered a static file, part of the >platform that gets shipped with Cordova. Platform-specific settings should >be in your main config.xml file, inside of <platform> tags, where they >will >override the defaults when the platform's config.xml is generated. > >Ian Matt Scafidi-McGuire | Senior User Interface Developer V: 877.327.8422 matt.scafidi-mcgu...@dealer.com | www.dealer.com
