-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
post-argument-parsing hook #81
Comments
I don't think what you describe exists today. However, I'm having a hard time imagining a good use case for such a feature. Could you maybe give a short example of how such a feature would be used? |
@ggilder Sure. The use I have in mind is for global options. As far as I'm aware, there is no way to invoke the |
Hmm, maybe I'm mistaken but setting defaults seems pretty straightforward already. I'd probably use something like the following: GLOBAL_DEFAULTS = { foo: 'bar' }
global_option('--foo VALUE') { |val| GLOBAL_DEFAULTS[:foo] = val } Similarly with command options, the COMMAND_DEFAULTS = { prefix: 'foo' }
command :bar do |c|
c.option '--prefix STRING', String, 'Adds a prefix to bar'
c.action do |args, options|
options.default COMMAND_DEFAULTS
end
end
# repeat with other commands... As far as post-processing the options, the examples you give seem pretty domain-specific, so my instinct would be to delegate that to your own classes outside of the commander DSL: class AppSetup
def self.setup(options)
# your own logic to do db queries, set up objects, etc.
end
end
command :bar do |c|
c.action do |args, options|
# delegate post-processing, setup, etc. to your domain objects
AppSetup.setup(options)
end
end Does that address the use cases you're thinking of? If not, maybe a short code sample of what you're imagining would be helpful for discussion. |
What @smackesey is seems to be describing and what I see useful is to allow initialization based on global options. For example a program doing DB query may want to open a DB connection regardless of command in use. And without need for all commands to call same initialization method.
|
@akostadinov practically speaking, couldn't you just run that initialization code before the commander stuff? e.g.: def run
# put common initialization here
program :name, 'MongoQuery'
default_command :ui
# etc...
end I don't really see what advantage you'd get by putting that in a commander hook. |
@ggilder , in your example I don't have access to parsed |
Thanks, I think I see the use case now. I think this would be a relatively straightforward change to |
Please comment on pull #96 |
On the other hand this whole feature might be stupid after all. If I want to get a database, then I can have a method to get me the DB connection object (in contrast with setting up an Everybody interested, please comment. |
I guess my assumption is that on something like However, I personally agree with the skepticism — for something that needs a complex level of setup I would probably prefer to have that managed by my own module, using Commander as the translation between CLI and this module. |
This issue was moved to commander-rb/commander#5 |
Is there any way to do some processing (add to options object, set instance variables and so on) after all options have been parsed but before any command has been run? If not, this would be a useful feature (I'd be willing to implement it in a PR)-- if it exists, then I think it should be mentioned in the README.
The text was updated successfully, but these errors were encountered: