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: <20150526163836.50664E0779@git1-us-west.apache.org>
Date: Tue, 26 May 2015 16:38:36 +0000 (UTC)

Github user kamrik commented on a diff in the pull request:

    https://github.com/apache/cordova-windows/pull/84#discussion_r31053467
  
    --- 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 --
    
    Do we want to keep PlatformHandler and PlatformApi as 2 separate classes long term?
    From the current CLI style workflow, the methods in PlatformHandler seem to be like something private that should be hidden from the user. But actually some of the methods like getWwwDir() might be very useful to the user. An example would be when the web app is very large and copying it all on updateWww become a heavy operation. But if the user knows where to copy the files to, he can fine-tune his workflow to only copy changes which is a very common case when working with gulp/grunt watch.


---
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