There are certainly a lot of hurdles to making it work, but I still think the definition of the parameter belongs in this trait as well. The approach Laravel uses to turn the signature into the underlying definitions at the Symfony level adds some frustrating barriers. I think we could consider digging into that to do this more elegantly down the road. In the short term, what do you think about simply adding it at the signature level?
in this class,
public function configureHasServerIdParameter()
{
$this->signature .= PHP_EOL.' {server_id? : The server id to use}';
}and in BaseCommand we can process this in the __construct()or method, before the call to parent::__construct() (and therefore before the the signature gets parsed and processed).
$methods = get_class_methods($this);
$traitConfigureMethods = Arr::where($methods, function ($value, $key) {
return preg_match('~configure.+parameter~i', $value);
});
foreach ($traitConfigureMethods as $traitConfigureMethod) {
$this->$traitConfigureMethod();
}There's a convention to note in that regex - configure{traitName}Parameter. There's certainly room to rethink that, but do note that there are some built in Laravel methods we will catch if we try to match just configure*.
This convention will need to be something the team all understands and can replicate in future traits.
That will get us working with the full concern abstracted.
Originally posted by @Jamesclark32 in #28 (comment)
There are certainly a lot of hurdles to making it work, but I still think the definition of the parameter belongs in this trait as well. The approach Laravel uses to turn the signature into the underlying definitions at the Symfony level adds some frustrating barriers. I think we could consider digging into that to do this more elegantly down the road. In the short term, what do you think about simply adding it at the signature level?
in this class,
and in
BaseCommandwe can process this in the__construct()or method, before the call toparent::__construct()(and therefore before the the signature gets parsed and processed).There's a convention to note in that regex -
configure{traitName}Parameter. There's certainly room to rethink that, but do note that there are some built in Laravel methods we will catch if we try to match justconfigure*.This convention will need to be something the team all understands and can replicate in future traits.
That will get us working with the full concern abstracted.
Originally posted by @Jamesclark32 in #28 (comment)