-
Notifications
You must be signed in to change notification settings - Fork 4
Add args for commands #5
Comments
@clubdeuce I fear if I focusing on the CLI framework at first I will get bogged down in architecting and not actual implement the functionality that is higher priority short term. So short term I would prefer not to focus on the CLI framework but instead implement more functionality, especially because we have a lot of functionality to implement. But what about short term for the API? I have been assuming you would handle it much like how WordPress handles API routing and that being with an array of match patterns as keys and result patterns as values. For example (something like):
Then later if we evolve the CLI commands we'd only need to change it like so:
Will something like this not work? |
@mikeschinkel Yes, your assumption regarding the implementation of the API is essentially correct. And, yes, it does work. That being said, I do not understand your response. This issue is that of using positional arguments versus named arguments. My intention for opening this issue was to refactor existing commands to use, and implement all future commands using, arguments that are named as opposed to positional. I view this as analogous to method signatures. Using named arguments will allow us to not have to go back and change the API processing if the command changes. We would only need to update the route to accommodate new parameters. Not being well versed in BASH, I am not sure how easy this is to implement. |
@clubdeuce So I completely agree with you in concept and also long term. Short term I am hoping to avoid implementing a proper CLI framework, at least for a while.
Therein lies the rub. When I previously looked at how to do a robust CLI I did not find a good consensus on how best to implement a Bash CLI framework. Every example I looked at was significantly different, and significantly complex. What I would like to do is build out the functionality of the commands we need and once we get to parity with VVV+VV and Pressmatic then go back and refactor the commands to use a CLI framework, which I may have to architect and build too. And the more experience I have writing Bash the easier it will be to decided on an implement a proper CLI framework. Is it possible for use to share maintenance of the API/Command mapping file in the short term? |
@mikeschinkel See my commit against this issue above. |
For example:
box import_db filename
would be much easier to implement with the API (and allow for future extensibility) if it looked like this:
box import_db --importfile filename
Can we make that happen?
The text was updated successfully, but these errors were encountered: