incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: CB-280 - Improve layout of cordova-js scripts
Date Mon, 19 Mar 2012 18:31:00 GMT
These are two use cases I see so far in the various cordova JS platform
implementations for module overriding:

1. I want to completely override a common module. This seems solved with
the proposed convention of /platform/<platform>/foo.js overriding
/cordova/foo.js at build time, instead of the current "objects" property
on the platform definition JSON file.
2. I want to override or add a few methods on the common foo module (or
its prototype) with some platform specific stuff. BlackBerry and iOS do a
fair bit of this. Current suggested method is using the "merges" property
on the platform definition JSON file. No proposed solution to this in the
new re-architect? Interestingly most platforms can settle for overriding
the prototype methods if the parent object to override has a prototype.
Some platforms, like iOS, however, do NOT allow native code prototype
overriding so we clobber a specific instance's methods instead. I.e:

navigator.geolocation.getCurrentPosition = require('ios-specific geo
plugin').getCurrentPosition;

I guess this new approach would also eliminate the need to have an
explicit common platform definition, as that should just be all of the
scripts located under the /cordova directory. That being said, the current
implementation has a few of what Pat calls "scripts" that are defined/used
as modules: the channel, utils, builder and base cordova scripts are all
wrapped as modules and used as such throughout the plugin JS files. The
current path -> module id mapping for these scripts (where applicable) is:

/lib/cordova.js is "cordova"
/lib/channel.js is "cordova/channel"
/lib/require.js is in-lined as a script that scopes to the entire built
cordova.js file
/lib/bootstrap.js is in-lined
/lib/builder.js is "cordova/builder"
/lib/utils.js is "cordova/utils"

What about the location of the exec module for each platform? Assume the
existence of an exec.js in each platform/<platform>/ directory?


On 3/19/12 9:17 AM, "Patrick Mueller" <pmuellr@gmail.com> wrote:

>On Mon, Mar 19, 2012 at 11:46, Patrick Mueller <pmuellr@gmail.com> wrote:
>
>> On Mon, Mar 19, 2012 at 11:37, Gord Tanner <gord@tinyhippos.com> wrote:
>>
>>> +1
>>>
>>> If we could somehow lay things out that we can handled more of the
>>> platform
>>> specific insertions and scripts in a convention over configuration
>>>basis
>>> that would be a huge win.
>>>
>>> If I have foo.js in the main folder and a blackberry/foo.js.  I would
>>> expect it would overwrite the foo.js during blackberry's build and only
>>> include the platform specific one in the compiled source.
>>
>>
>> Yup.  Again, kinda crude, as this is simple to do for single files, may
>> get more complicated if you want to do something like 'delete common
>>thing,
>> don't replace it with anything', or dealing with subdirectories.  We can
>> defer those potential complications until we hit them.
>>
>
>Well, dang it, I already have a use case for this 'delete the common
>thing,
>don't replace it with anything' requirement.
>
>    https://issues.apache.org/jira/browse/CB-348
>
>It turns out that today, this is just an iOS issue, today, near as I can
>tell.  What if we have other platforms that need this later (or even
>today!)?
>
>I suppose, for now, we can just copy the ios console.js (or whatever it
>ends up being called) into each platform that needs it, but ... that's
>obviously a little problematic.  To some extent, it would be nice to have
>a
>'portable' console.js in a common place, and then let each platform decide
>whether or not to include it at all.  Platforms that didn't want it (all
>but iOS?) could have an empty 'console.js' module in their platform dir,
>but that seems dumb.
>
>Almost seems like the best thing is some kind of configuration (ah
>gr*&()*&) where you'd say, for iOS, "here's an additional module I want
>you
>to add".  And then, we'd need a new directory tree of these 'portable, but
>not used by everyone' modules.
>
>-- 
>Patrick Mueller
>http://muellerware.org


Mime
View raw message