cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Scafidi-McGuire <Matt.Scafidi-McGu...@dealer.com>
Subject Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms
Date Mon, 14 Apr 2014 16:41:18 GMT
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" <iclelland@chromium.org> wrote:

>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




Matt Scafidi-McGuire | Senior User Interface Developer
V: 877.327.8422
Matt.Scafidi-McGuire@dealer.com | www.dealer.com



Mime
View raw message