cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <>
Subject Re: [DISCUSS] Local plugin configuration
Date Fri, 28 Aug 2015 17:42:02 GMT
On Thu, Aug 27, 2015 at 6:47 PM, Shazron <> wrote:
> 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>.
ok. I was mistaken. I though that if you have a <preference> tag
inside the <plugin> tag, it tells the plugman that this preference is

So what I'm missing from the plugin spec is the possibility to
describe what preferences are available/required for the plugin to

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

Is there already a JS API defined for plugins, that hey should expose?
i.e we could then add the

/* {object} */ Plugin.getConfiguration();

to it.

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

I think the plugins need to be backward compatible, you could add a
fallback information, like
   <param name="splashImage" defaultPreference="SplashScreenImage"
default="cordova.png" />

and plugman should copy over all params anyways, right?

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

regards, toby

> [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 <>
> wrote:
>> 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.
>> WDYT?
>> Regards, Toby
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message