incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Walters <deedu...@gmail.com>
Subject Re: Pluginization FTW
Date Wed, 25 Apr 2012 12:29:21 GMT
I would agree that it shouldn't be "necessary" for the addPlugin API
(more like addNamespace), however it was nice to have during my
development.  If you look at the addPlugin API you'll notice it waits
until DOMContentLoaded is fired so that the native browser globals
don't overwrite the plugin.  It then calls a modified builder module
which handles overriding/merging in the various properties of the
plugin.

Without addPlugin/mergePlugin there will certainly be repetition of
code and greater potential for plugins to unintentionally override
namespace of other plugins.

On Tue, Apr 24, 2012 at 5:42 PM, Brian LeRoux <b@brian.io> wrote:
> +1
>
> On Tue, Apr 24, 2012 at 3:31 PM, Filip Maj <fil@adobe.com> 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" <fil@adobe.com> 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" <deedubbu@gmail.com> 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.
>>>
>>

Mime
View raw message