[jira] [Commented] (CB-388) REMOVE "plugins" and "PhoneGap" global objects from JavaScript implementation

["Patrick Mueller (Commented) (JIRA)" <ji...@apache.org>]

    [ 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