+1
On Tue, Apr 24, 2012 at 3:31 PM, Filip Maj <[email protected]> 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" <[email protected]> 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! >> >>[1] http://wiki.apache.org/cordova/PluginDesign >> >>On 4/18/12 1:58 PM, "Drew Walters" <[email protected]> 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: >>> >>>https://github.com/deedubbu/cordova-blackberry-pluggable >>> >>>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. >> >
