cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms
Date Mon, 14 Apr 2014 14:18:27 GMT
On Mon, Apr 14, 2014 at 9:57 AM, Matt Scafidi-McGuire <
Matt.Scafidi-McGuire@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message