Duplicate plugin preferences - any docs on config/defaults xml mechanisms

[Matt Scafidi-McGuire <Ma...@dealer.com>]

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.

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

Thanks,
MattDuplicate plugin preferences - any docs on config/defaults xml mechanisms



Matt Scafidi-McGuire | Senior User Interface Developer
Matt.Scafidi-McGuire@dealer.com<ma...@dealer.com>

[Dealer.com]

Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms

[Bryan Higgins <br...@bryanhiggins.net>]

Sounds like a bug if two preferences of the same name end up in the
platform config.xml. I would encourage you to log this in our JIRA system:

https://issues.apache.org/jira/browse/CB

Platform specific preferences can be specified using the platform element,
which I recently discovered was undocumented.

https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blobdiff;f=docs/en/edge/config_ref/index.md;h=9c32672403f1ceffce4278aa7e1fa6add7065946;hp=2df993147957cfe6f626f8a08e4a455557889e4d;hb=7598207d0e4395905c009c056947a5a7c9930b1a;hpb=b28cb8be613f637f28dbfd3c0db2bd193e7abb51



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.
>
> 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.  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?
>
> Thanks,
> MattDuplicate plugin preferences - any docs on config/defaults xml
> mechanisms
>
>
>
> Matt Scafidi-McGuire | Senior User Interface Developer
> Matt.Scafidi-McGuire@dealer.com<ma...@dealer.com>
>
> [Dealer.com]
>
>
>
>
>
>

Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms

[Andrew Grieve <ag...@chromium.org>]

I think the original design of this was that duplicates are expected, and
the last one wins. Not saying that's the best solution, but I'm pretty sure
that's how it works.


On Mon, Apr 14, 2014 at 8:41 AM, Matt Scafidi-McGuire <
Matt.Scafidi-McGuire@dealer.com> wrote:

> 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" <ic...@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
>
>
>

Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms

[Matt Scafidi-McGuire <Ma...@dealer.com>]

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" <ic...@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

Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms

[Ian Clelland <ic...@chromium.org>]

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