cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Duplicate plugin preferences - any docs on config/defaults xml mechanisms
Date Mon, 14 Apr 2014 20:21:55 GMT
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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message