On Thu, Aug 27, 2015 at 6:47 PM, Shazron <[email protected]> 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:
> http://docs.phonegap.com/en/edge/guide_plugins_plugin_spec.md.html
>
> 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
required.
So what I'm missing from the plugin spec is the possibility to
describe what preferences are available/required for the plugin to
work.
> 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
<feature>
<param name="splashImage" defaultPreference="SplashScreenImage"
default="cordova.png" />
</feature>
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 <[email protected]>
> 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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
