cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kamrik <...@git.apache.org>
Subject [GitHub] cordova-windows pull request: Draft implementation for Unified pla...
Date Wed, 27 May 2015 15:19:38 GMT
Github user kamrik commented on a diff in the pull request:

    https://github.com/apache/cordova-windows/pull/84#discussion_r31144880
  
    --- Diff: template/cordova/Api.js ---
    @@ -0,0 +1,54 @@
    +
    +/*jshint node: true*/
    +
    +var path = require('path');
    +
    +var buildImpl = require('./lib/build');
    +var requirementsImpl = require('./lib/check_reqs');
    +
    +function PlatformApi () {
    +    // Set up basic properties. They probably will be overridden if this API is used
by cordova-lib
    +    this.root = path.join(__dirname, '..', '..');
    +    this.platform = 'windows';
    +
    +    if (this.constructor.super_){
    +        // This should only happen if this class is being instantiated from cordova-lib
    +        // In this case the arguments is being passed from cordova-lib as well,
    +        // so we don't need to care about whether they're correct ot not
    +        this.constructor.super_.apply(this, arguments);
    +    }
    +}
    +
    +PlatformApi.prototype.build = function(context) {
    +    var buildOptions = context && context.options || [];
    +    return buildImpl.run(buildOptions);
    +};
    +
    +PlatformApi.prototype.requirements = function () {
    +    return requirementsImpl.check_all();
    +};
    +
    +function PlatformHandler() {
    --- End diff --
    
    The only reason I kept the parser property when switching to PlatformProject was backwards
compatibility as well, with the hope to deprecate it once the rest of the code is changed
to use methods of the PlatformProject directly. Actually there are very few direct calls to
the parser left in cordova-lib, it's mostly used by the tests (which will have to change anyway).
    
    The "prepare" has several sub-steps which might be interesting to the outside user as
separate steps:
     * apply plugin config munges
     * apply config.xml based config changes to global project files
     * copy www
    So I'm not sure prepare should be a single black box, but the above steps should definitely
be methods of the PlatformApi rather than of some sub-object, and there can be a "prepare"
method that executes all 3 of those steps for convenience.
    
    Here is an example usage of a PlatformProject from a gulp file with separate calls to
the above 3 stages.
    https://github.com/kamrik/cordova-api-example/blob/master/gulpfile.js#L105
    The plugin config munges are applied as part of gulp "create" task, and the other two
as part of gulp "build" task. This allows for a much faster build for projects with many plugins.
But slower for adding/removing plugins (which is a less frequent operation).
    
    Whichever direction you decide to take it, thanks for picking up this API work!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message