incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gord Tanner <g...@tinyhippos.com>
Subject Re: Pluginization FTW
Date Thu, 26 Apr 2012 19:57:29 GMT
I would like to have a single module that holds all of the native to
javascript code.

so:
- exec
- successCallback
- errorCallback
- nativeReady stuff

kinda a one stop shop for all things native bridge like.

I don't like how it is mixed together with the cordova module right now.

cordova as a module should really just have:

require
define


On Thu, Apr 26, 2012 at 3:36 PM, Filip Maj <fil@adobe.com> wrote:

> Love this.
>
> What is the refactor of the bridge out of exec, exactly?
>
> On 4/26/12 12:26 PM, "Gord Tanner" <gord@tinyhippos.com> wrote:
>
> >I would imagine plugins should be able to use the builder code cordova.js
> >uses to augment or extend namespaces in the dom:
> >
> >
> https://github.com/apache/incubator-cordova-js/blob/master/lib/common/comm
> >on.js
> >
> >Builder:
> >
> https://github.com/apache/incubator-cordova-js/blob/master/lib/common/buil
> >der.js
> >
> >We do need to clean this API up a bit before exposing it to the masses,
> >but
> >it would be neat if a plugin module could use this to drop objects into
> >the
> >dom:
> >
> >var objects = { foo: { path: "myplugin/foo"};
> >var builder = cordova.require('cordova/builder');
> >
> >builder.build(objects).into(navigator);
> >
> >An awesome approach for plugin's would be to not to provide a platform,
> >but
> >more of a collection of tools (a la unix) that would make it easy for them
> >to develop.
> >
> >- cordova.require and cordova.define (they can package themselves as a
> >module and gateway to use our modules)
> >- cordova/exec (would be nice to finally refactor out the cordova/bridge
> >module)
> >- cordova/utils (toolbox stuff)
> >- cordova/builder (better API needed for building up dom namespaces, not
> >required but there to use)
> >
> >
> >
> >On Thu, Apr 26, 2012 at 3:05 PM, Brian LeRoux <b@brian.io> wrote:
> >
> >> On Wed, Apr 25, 2012 at 5:29 AM, Drew Walters <deedubbu@gmail.com>
> >>wrote:
> >> > 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.
> >>
> >> Seems like a docs issue more of an API surface issue to me.
> >>
> >> > Without addPlugin/mergePlugin there will certainly be repetition of
> >> > code and greater potential for plugins to unintentionally override
> >> > namespace of other plugins.
> >>
> >> could add those to util
> >>
> >
> >
> >
> >--
> >Gord Tanner
> >Senior Developer / Code Poet
> >tinyHippos Inc.
> >@tinyhippos
>
>


-- 
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message