Skip to content

Creating a class for carrying out rails commands. #11355

Merged
merged 1 commit into from Jul 8, 2013

5 participants

@wangjohn
wangjohn commented Jul 8, 2013

This class encapsulates a lot of logic that wasn't very object oriented. The file for defining rails commands had quite a bit of logic inside of it which could be refactored. I've created a new class which handles the delegation of the commands.

Helper methods have been created to try to make things more logical and easy to read.

@wangjohn wangjohn Creating a class for carrying out rails commands.
This class encapsulates a lot of logic that wasn't very object oriented.
Helper methods have been created to try to make things more logical and
easy to read.
f1f249d
@mdespuits

👍 Awesome!

@rafaelfranca rafaelfranca merged commit b025fca into rails:master Jul 8, 2013

1 check passed

Details default The Travis CI build passed
@carlosantoniodasilva carlosantoniodasilva commented on the diff Jul 8, 2013
railties/lib/rails/commands/commands_tasks.rb
+ end
+
+ def runner
+ require_command!("runner")
+ end
+
+ def new
+ if %w(-h --help).include?(argv.first)
+ require_command!("application")
+ else
+ exit_with_initialization_warning!
+ end
+ end
+
+ def version
+ ARGV.unshift '--version'
@carlosantoniodasilva
Ruby on Rails member

Should use the argv attribute instead of the ARGV constant?

@rafaelfranca
Ruby on Rails member
rafaelfranca added a note Jul 8, 2013

As far I could understand the next command will use the ARGV constant to perform the actions, so we have to mutate the ARGV

@wangjohn
wangjohn added a note Jul 8, 2013

Yes, unfortunately, the file that is required in this command will look for --version to be the first argument in ARGV. The reason I choose to use ARGV instead of the argv instance variable is because it would be more clear that we are actually mutating the elements.

I'm using argv elsewhere when we only need to read. I'm still trying to think of a better way to get around all this terrible ARGV manipulation.

@carlosantoniodasilva
Ruby on Rails member

I feel like manipulating the argument vs manipulating a constant would be better to go with the first, you can test more easily and the end result for the user (ie mutating ARGV and commands working) would be the same, since ARGV is what is passed as input to this class. As long as the warning shows that it mutates the variable, we should be good (Otherwise there might be no gain on passing ARGV as input since you could reference the constant everywhere for reading as well). But that's my opinion, others might disagree ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@carlosantoniodasilva carlosantoniodasilva commented on the diff Jul 8, 2013
railties/lib/rails/commands/commands_tasks.rb
+ end
+
+ def help
+ write_help_message
+ end
+
+ private
+
+ def exit_with_initialization_warning!
+ puts "Can't initialize a new Rails application within the directory of another, please change to a non-Rails directory first.\n"
+ puts "Type 'rails' for help."
+ exit(1)
+ end
+
+ def shift_argv!
+ ARGV.shift if ARGV.first && ARGV.first[0] != '-'
@carlosantoniodasilva
Ruby on Rails member

Same here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@wangjohn wangjohn deleted the wangjohn:class_for_rails_commands branch Jul 8, 2013
@guilleiguaran
Ruby on Rails member

great!!!! ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.