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: https://github.com/apache/incubator-cordova-js/blob/master/lib/platform/and roid.js#L120-L125
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: https://github.com/apache/incubator-cordova-js/blob/master/lib/platform/bla ckberry.js#L27-L39 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" <[email protected]> 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 <[email protected]> wrote: >> >>>I think we can all agree that both of these are not the ideal solution >>>but >>>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 >>can >> 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 >>next >> 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, >>let's >> all use it a little bit, and *then* start reasoning about what the >> problems with it are how to solve them. >>
