[
https://issues.apache.org/jira/browse/CB-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239565#comment-13239565
]
Patrick Mueller commented on CB-388:
------------------------------------
copied from [CB-298|https://issues.apache.org/jira/browse/CB-298], because I
think we should move the "what to do in the future" discussion here.
bq. As far some guidance on how to move over, I would recommend employing
cordova's define and require in cordova-js. For a hasResource equivalent, I
would check if cordova.require('mymoduleid') throws an exception. If so, then
go ahead and use cordova.define. If not, it's already defined, as the user does
in your above example, simply return out. In the same vein, cordova.define can
be used as a replacement for addResource.
bq. The only other change would be to the call to exec. Users can go with
either calling cordova.exec directly, or if they want to use the same require
syntax they can roll with cordova.require('cordova/exec').
So, one thing we have to ask is if we really want to expose {{define()}} and
{{require()}} as core API. I certainly want to continue using them as core
building blocks, but not sure it makes sense to equate modules with "plugins".
Specifically, while I suspect we want all plugins implemented as modules, they
are really two separate beasts.
For instance, there IS no easy API to check to see if a module is "available".
If you reference a module, you assume it's available. If you really don't
know, then you have to wrap in a {{try/catch}}, which is very unfriendly.
Another for instance, it seems likely that we will want to provide other
"plugin" capabilities, like the ability to load a "resource" relative to the
plugin. Again, there IS no API to do this in the CJS universe. AMD has such
notions, but they're baked into their module system, which ain't right.
What I'm suggesting is that we probably want to have a first class notion of a
"plugin", that we can provide additional API on, over-and-above what the module
system provides. Extending the module system, like what AMD does, is not a
great story as it limits our freedom-of-action w/r/t replacing the module
system - basically, we can't. Today, the story we are limping towards is "use
our module system, or in the future we plan on allowing you to use a different
module system, as long as it passes our compliance tests". Which will be good
enough for the RequireJS's, almond's, pinf's, and Dojo's of the world.
Just to strawman a bit, here's a potential shape:
{noformat}
Cordova.getPlugin(aPluginName)
Returns the specified plugin object, or null if not available.
aPluginName - a fully-qualified Cordova plugin name (whatever that means)
Cordova.getPluginResource(aPlugin, aResourceName, options)
Returns the specified resource, or null if not available.
aPlugin - a plugin object, or name of a plugin
aResourceName - a name relative to the installed plugin (whatever that means)
options - provides hints about the shape of the returned object.
eg, "give me a Blob" or "give me an Image" or "give me an
HTML element installed in a DocumentFragment", etc.
Cordova.getPluginMetaData(aPlugin)
Returns the meta-data about a plugin (eg, package.json contents)
aPlugin - a plugin object, or name of a plugin
{noformat}
It might well be that it makes sense for one of these "plugin objects" to
actually be the "module exports" or a module, in some kind of algorithmically
defined way. Eg:
require(aPluginName) == Cordova.getPlugin(aPluginName)
But I don't see a hard requirement to do this. It's not out of the question
that you could see "module names" as the equivalent of Java Class names
(implementation), but "plugin names" as more of a Java "interface", where you
tie the two together in your meta-data. For instance, I might want to have a
plugin which has completely different implementations for iOS and Android, and
specify that in my plugin metadata.
> REMOVE "plugins" and "PhoneGap" global objects from JavaScript implementation
> -----------------------------------------------------------------------------
>
> Key: CB-388
> URL: https://issues.apache.org/jira/browse/CB-388
> Project: Apache Callback
> Issue Type: Bug
> Components: CordovaJS
> Affects Versions: 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0
> Reporter: Filip Maj
> Assignee: Filip Maj
> Priority: Minor
> Fix For: 2.0.0
>
>
> The {{plugins}} and {{PhoneGap}} JavaScript globals should be removed in 2.0.
> Deprecation notices were set up in 1.6 for these methods/objects.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
