Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
From: kamrik <git@git.apache.org>
To: dev@cordova.apache.org
Reply-To: dev@cordova.apache.org
References: <git-pr-84-cordova-windows@git.apache.org>
In-Reply-To: <git-pr-84-cordova-windows@git.apache.org>
Subject: [GitHub] cordova-windows pull request: Draft implementation for
 Unified pla...
Content-Type: text/plain
Message-Id: <20150527151938.9D245DFDF1@git1-us-west.apache.org>
Date: Wed, 27 May 2015 15:19:38 +0000 (UTC)

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