incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: [DISCUSSION] standard layer to exec : regCommandProxy
Date Thu, 23 Feb 2012 18:05:00 GMT
Two ways so far that I have employed.

1. If you need to override an entire module, you can do so in the platform
definition file under platform/, like android does for the File and
FileError objects:

2. If you need to override one or a few methods on a prototype of a common
module, I do so in the "initialize" method of the platform definition
file. For example, BlackBerry needs to override only a couple of methods
on some File API modules:

Let me know if more clarification is needed.

P.S. Obviously neither of these approaches is "pretty" - there are better
approaches that can probably save us a few bytes in the js files - the
comments say as much. Something definitely that we should work on once we
land it!

On 12-02-23 9:57 AM, "Drew Walters" <> wrote:

>+1, but can we settle on what the currently recommended way of
>providing platform specific overrides is.  Ugly code is ugly code, but
>it should at least be homogeneously ugly.
>On Thu, Feb 23, 2012 at 11:51 AM, Filip Maj <> wrote:
>>>I think we can all agree that both of these are not the ideal solution
>>>both work fine for now.
>> This, in my mind, sums up this thread.
>> Yes, there are problems and ugliness in cordova-js. However I think we
>> all see the benefit in moving to a unified JS approach where JavaScript
>> modules are king.
>> Initially, yes, there are going to be some platform-specific overrides.
>> Are they ugly? Certainly. But let's first get the current fugly
>> implementation of cordova-js on all platforms, and then start iterating
>> and improving and removing/refactoring platform-specific stuff in the
>> few releases before 2.0.
>> Once we got it incorporated into Android, we were passing more tests in
>> mobile-spec than the previous per-platform JS file implementation. Let's
>> make this happen on other platforms, get all of the maintainers and
>> committers comfortable with how the project works and is structured,
>> all use it a little bit, and *then* start reasoning about what the
>> problems with it are how to solve them.

View raw message