RE: [DISCUSS] Local plugin configuration
I like this design (we should have had this in the first place) - but am
concerned of the breaking nature.
Do we have a specific case of a name conflict that we know of? Another way to
do this would be to use naming conventions - similar to a namespace. The
recommendation would be to prefix the preference name with the plugin id -
though that makes preference names rather long and does not guarantee anything.
-Nikhil
-Original Message-
From: Shazron [mailto:shaz...@gmail.com]
Sent: Tuesday, September 1, 2015 4:33 PM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Local plugin configuration
>
>
> So what I'm missing from the plugin spec is the possibility to
> describe what preferences are available/required for the plugin to
> work.
>
>
It being under would imply this but I think you are asking about the
way currently things are. Yeah right now if preference is not added under the
a user wouldn't know about it.
> > 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.
>
No there is no API for this currently.
> >
> > 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 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
> default="cordova.png" />
>
>
> and plugman should copy over all params anyways, right?
>
They still won't be configured properly, since older platforms won't know what
to do with these new attributes, and won't save them for plugins to access. The
config parser is part of the platform. The plugin however, could read this
config.xml themselves of course but we're trying to solve this in a generic way
that is easier for plugin authors.
Also, I found an issue already filed (by me) essentially already asking for
what you want:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-6458=01%7c01%7cnikhilkh%40microsoft.com%7c358da174d2c54994660308d2b325da62%7c72f988bf86f141af91ab2d7cd011db47%7c1=jkto%2fhvkmiVg5UX9j2uzVYlSCroxjLRDahhoYwj%2fY%2b0%3d
Perhaps we could continue on that issue, I've tentatively labeled the issue for
cordova-ios-5.0.x
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Local plugin configuration
>
>
> So what I'm missing from the plugin spec is the possibility to
> describe what preferences are available/required for the plugin to
> work.
>
>
It being under would imply this but I think you are asking about
the way currently things are. Yeah right now if preference is not added
under the a user wouldn't know about it.
> > 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.
>
No there is no API for this currently.
> >
> > 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 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
>
> default="cordova.png" />
>
>
> and plugman should copy over all params anyways, right?
>
They still won't be configured properly, since older platforms won't know
what to do with these new attributes, and won't save them for plugins to
access. The config parser is part of the platform. The plugin however,
could read this config.xml themselves of course but we're trying to solve
this in a generic way that is easier for plugin authors.
Also, I found an issue already filed (by me) essentially already asking for
what you want:
https://issues.apache.org/jira/browse/CB-6458
Perhaps we could continue on that issue, I've tentatively labeled the issue
for cordova-ios-5.0.x
Re: [DISCUSS] Local plugin configuration
On Thu, Aug 27, 2015 at 6:47 PM, Shazron shaz...@gmail.com 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 tri...@apache.org
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: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Local plugin configuration
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. 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 platforms. 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. [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 tri...@apache.org 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: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
