cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <>
Subject Re: [DISCUSS] Local plugin configuration
Date Fri, 28 Aug 2015 01:47:51 GMT
I think this is way overdue, good idea.

I think <preference> tags can already be global to the plugin, and these
are plugin variables -- so it will conflict:

I think its safer to just add it under <feature>. All relevant platforms
will now need to support reading of these new tags, and have a way for
plugins to access them. This would be a major platform version bump because
of a new API needed for plugins (which is next for cordova-osx and
cordova-ios but the other platforms already have their major version
bumps). We could avoid a major version bump if we could shoehorn
namespacing the plugin preferences into the current settings [1].

The problem would be, if the new tags are specified in plugin.xml, and you
didn't have the newer platform installed, the plugin won't be configured
properly. This could be mitigated by having the required platform version
specified in an <engine> tag, but this will exclude your plugin from older

A backwards compatible way is if these new tags are specified under
<feature>, copy the <preferences> into the platform config.xml. This method
however brings up the name collision problem.

In any case, to have this new feature properly implemented requires a clean
break, it can't be truly backwards compatible with different platform

[1] On iOS, the settings dict, has a key called PluginPreferences (or
similar), whose value is a dict which contains -> key: feature name, value:
dict. This dict would contain the plugin preferences.

On Tue, Aug 25, 2015 at 10:13 PM, Tobias Bocanegra <>

> Hi,
> I noticed that the current way to configure plugin behaviour is done
> through the <preference/> tags in config.xml. The cordova plugin
> registry shows 1106 plugins, so the chance that 2 plugins have a
> preference name collision is relatively high.
> I suggest that plugins could be configured in the <feature/> tag and
> that plugins have a possibility to read their config.
> so analog to the platform tag, we could specify plugin local preferences.
> eg:
> <feature name="File">
>   <param name="ios-package" value="CDVFile" />
>   <param name="onload" value="true" />
>   <preference name="extraFilesystems" value="library" />
> </feature>
> or
>     <feature name="SplashScreen">
>         <param name="ios-package" value="CDVSplashScreen" />
>         <param name="onload" value="true" />
>         <preference name="image" value="...resource name..."/>
>         <preference name="autoHide" value="true"/>
>     </feature>
> analog to the required global preference, a plugin can specify a
> required local preference in its plugin.xml description. eg
>    <feature-preference name="image" />
> Similar it should be possible to configure the plugin in the
> non-platform config.xml, inside the plugin tag. eg:
> <plugin name="cordova-plugin-splashscreen" spec="~2.1.0">
>         <preference name="image" value="...resource name..."/>
>         <preference name="autoHide" value="true"/>
> </plugin>
> and on updating the platform, it should copy those preferences into
> the <feature> tags.
> Regards, Toby
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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