Replace Command arguments with MakerParams #626
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently every maker abuses the intended usage of
Command
arguments - which were meant to be values that are passed to a command. E.g.Command
arguments can either be required or optional. But, due to the way all current Makers useCommand
arguments as questions - they are all optional in regards to their intended usage.This PR introduces a new
MakerParam
object that is stored inAbstractMaker::makerParams
with agetMakerParamValue()
andsetMakerParam()
*open to suggestions on naming conventionsAs a side affect of declaring arguments first, then setting them. Makers rely heavily on what is essentially a
null|mixed
return type for$input->getArgument()
. An example would be passing arguments to a template - then the template has a conditional for that argument. In the example below, a value for$my-var
may not exist depending on the flow ofinteract()
While we would ideally like to get away from having to declare an argument, set a value, then get that value; this PR does not fully address that situation. One could use a conditional in the generate method or the newly introduced
$this->getMakerParamValue()
could returnnull
if that argument doesn't exist. The latter does not feel right IMO. As such, we are declaring all of the arguments first inconfigure()
so we don't run into aNotFoundException
or the like ingenerate()
. Open to ideas on this part...The
MakeRegistrationForm
maker was used to demonstrate the new feature. Other makers would be able to be converted in the future.