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 Fri, 27 Apr 2012 15:50:07 GMT
So, on BlackBerry it is possible to bundle additional resources with
the native code. If you throw the images in the Java source tree, they
get packaged up with the application and can be used by the native
code. I pushed an implementation of the ChildBrowser plugin [1] to my
repo which exhibits this strategy. The icons for the browser toolbar
are bundled with the native code and then accessible at run time. I
updated the sample to have child browser invocation as well.

However, there doesn't seem to be a declarative way to specify
additional resources. The WebWorks packager will only pull in
additional extensions, javascript, java src trees, compiled libraries
specified in the library.xml for the extension. It does not provide a
mechanism to specify arbitrary files that I can tell. It would be nice
to be able to specify things like images in library.xml.  Currently,
if the extension javascript needs to reference an image, I don't see a
way of bundling that image.

[1] https://github.com/deedubbu/cordova-blackberry-pluggable/tree/master/ext/cordova.childbrowser

On Thu, Apr 26, 2012 at 3:23 PM, Filip Maj <fil@adobe.com> wrote:
> Nice, I'm really liking this. Simpler than the massive object with various
> "path" properties, etc.
>
> I think we're getting closer to formalizing this!
>
> One outstanding question is: resources. Image files or anything of that
> like that may be necessary for a plugin.
>
> On 4/26/12 1:09 PM, "Drew Walters" <deedubbu@gmail.com> wrote:
>
>>In case it wasn't clear, in my implementation the plugins do use the
>>builder (modified version) to augment / extend namespace DOM. I
>>realize its difficult to tell right now what I changed but there is a
>>concatenated cordova.js (require.js, cordova.js, builder.js, utils.js,
>>channel.js, bootstrap.js) which has the modified cordova.addPlugin and
>>the modified builder:
>>
>>https://github.com/deedubbu/cordova-blackberry-pluggable/blob/master/ext/c
>>ordova.core/js/common/cordova.js
>>
>>I simplified the interface to it to just take strings such that the
>>plugin simply calls:
>>
>>cordova.addPlugin('navigator.battery', 'cordova/plugin/battery', false);
>>
>>to add the module at navigator.battery and the builder code handles
>>parsing 'navigator.battery' and doing proper merging/overriding.
>>
>>On Thu, Apr 26, 2012 at 2:57 PM, Gord Tanner <gord@tinyhippos.com> wrote:
>>> 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/co
>>>>mm
>>>> >on.js
>>>> >
>>>> >Builder:
>>>> >
>>>>
>>>>https://github.com/apache/incubator-cordova-js/blob/master/lib/common/bu
>>>>il
>>>> >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
View raw message