CLI

[tonylukasavage]

@FokkeZB brought up in #21 that a CLI for tiapp.xml would be beneficial. The initial idea in there was exposing only a subsection of the tiapp.xml API via CLI. I'd like to design a way that exposes the entire API reasonably.

My initial thoughts are something like this, which is not quite complete, but not far off:

usage: tiapp cmd target [value...]

examples:

    # get
    tiapp get version
    tiapp get sdk-version
    tiapp get property ti.defaultunit

    # set
    tiapp set version 3.4.0.GA
    tiapp set property ti.defaultunit dp
    tiapp set property ti.defaultunit dp string
    tiapp set deploymentTargets android,ipad,iphone

    #remove
    tiapp remove property ti.defaultunit
    tiapp remove module ti.paint
    tiapp remove module ti.paint android
    tiapp remove plugin ti.alloy

All commands would print the same return values that invoking the module API would.

[skypanther]

It seems like this would be best done in a wrapper module -- think grunt and grunt-cli. You'd just need to make sure to expose getter/setters for all the properties that the CLI would want to access.

[tonylukasavage]

yup @skypanther, i think you're right. tiapp.xml-cli would work since then it will prevent me from having to pull CLI modules into this module.

[FokkeZB]

I already know my favorites:

tiapp set version 3.4.0.GA
tiapp add module ti.paint android

[tonylukasavage]

damnit, I can't decide. I was going to put it in another module, but I feel like I should just do it here now. It changes the API in no way and the CLI will always need to be in sync with this module anyway. I may keep it here after all.

[FokkeZB]

I do think tiapp.xml is something used a lot as an API module dependency, like gittio. Brining get in a lot of extra dependencies for a CLI you don't use might be something to avoid.

On the other hand, for an end user of the CLI it might be confusing to see 2 packages