incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: Pluginization FTW
Date Tue, 24 Apr 2012 22:42:09 GMT

On Tue, Apr 24, 2012 at 3:31 PM, Filip Maj <> wrote:
> One thing I wanted to mention: I do not think it is necessary to have an
> "addplugin" api in JS.
> I think it should be completely up to the plugin author where and how they
> want to attach their JS API (if it exists) to global namespaces. Should
> not be something that the cordova framework mandates.
> The only thing we should be imposing on the JS side is, use:
> cordova.require("cordova/exec"); // reference to the exec function
> That's it. If they want to use our define+require methods, then that's
> great, but shouldn't be necessary IMO.
> On 4/24/12 3:03 PM, "Filip Maj" <> wrote:
>>I've had more time to go through your repo in detail, Drew, and in general
>>love what I see. I've factored in the main points that I understood into
>>our Plugin Design wiki article [1].
>>Very much like your clear separation of plugins from the core framework.
>>I think that the native side injecting the necessary js file (either for
>>the core framework or for individual plugins) is a great feature but am
>>skeptical this could work out in practice in a cross-platform manner.
>>I like it a lot. I think it's a perfect fit for a framework sitting on top
>>of the WebWorks platform.
>>Moving forward, to get this fleshed out ASAP, need to create similar
>>prototypes for Android, iOS and WP7, see what differences exist (if any),
>>work out the details, formalize/document, and then set tasks for 2.0!
>>On 4/18/12 1:58 PM, "Drew Walters" <> wrote:
>>>I've been experimenting with what it would look like for Cordova
>>>BlackBerry to be modified such that all the API are separated out into
>>>plugins. For those that want to cut to the chase, here's my repo:
>>>This repo is a representation of what the binary download would be for
>>>the end user and is not a fork of either cordova-js or
>>>cordova-blackberry-webworks.  Without being able to see the change
>>>history it might be difficult to tell what I've done so I'll provide
>>>some high level details here:
>>>1. Separated the native code and associated JavaScript into
>>>independent WebWorks extensions.  Previously there was only a single
>>>extension.  This allows us to make use of the BlackBerry WebWorks
>>>framework build/config tools which handle packaging up only the
>>>necessary code when building an app.
>>>2. All Cordova JavaScript is injected from the native side. No need to
>>>include cordova.js in your application, all the Cordova JavaScript is
>>>loaded before the applications pages load.
>>>3. WebWorks Extension API is hidden behind the existing Cordova Plugin
>>>interface.  Plugin developer doesn't really need to know that they are
>>>developing a WebWorks extension.  The only new interface requirement
>>>for a plugin is to invoke a new constructor.
>>>4. JavaScript API are defined as modules (no change) and can
>>>additionally call cordova.addPlugin(...) or cordova.mergePlugin(...)
>>>to override/merge global namespace.
>>>5. Installation of Cordova is a simple matter of copying a folder to
>>>the WebWorks SDK ext folder.
>>>6. Installation of a Cordova plugin is a simple matter of copying a
>>>folder to the WebWorks SDK ext folder.
>>>7. Enabling a Cordova plugin requires specifying the feature id in
>>>projects config.xml. plugins.xml is not used.
>>>Ok, that's a quick brain dump. The README contains a few more details.
>>>I plan on eventually pushing branches to my forks for cordova-js and
>>>cordova-blackberry-webworks which will show the actual code changes.

View raw message