We have moved our forum to GitHub Discussions. For questions about Phalcon v3/v4/v5 you can visit here and for Phalcon v6 here.

Rework CLI component

The CLI part of Phalcon has been neglected i dare say, there isn't even any category for it on the forums x) Routing and parameter handling are the most crucial part that should be reworked imho.


This is the current scheme for routing:

 $ php app/console.php [<task> [<action> [...<params>]]]

Arguments are linearly limited, you cannot have params without a task and action. I propose to use Symfony style task names, such as app:status. It may seem trivial, but with that you can redefine the command as

$ php app/console.php [<route>] [...<params>]

where route can be optional regardless of params if you allow the default route to be dispatched in such a case.

Also, when executing

    'task' => 'app',
    'action' => 'status-loop',

a corresponding AppTask::statusLoopAction() will be called.


# AppTask:statusAction()
$ php app/console.php app:status

# AppTask:indexAction()
$ php app/console.php app

# MainTask:indexAction()
$ php app/console.php --foo bar

(Currently, the router tries to dispatch the last example as --fooTask::barAction)


Parameters are not interpreted by the router, they are passed along blindly. If you pass in --my=option and --my option, they result in ["--my=option"] and ["--my","option"] respectively. I see no reason why Phalcon shouldn't be extend it so they both result in ["my"=>"option"]. Here is a simple parameters class which can explain what I'm after:

$p = new ConsoleParameters();
$p->fromString('--opt1=foo arg1 -flag2 --opt2 "bar baz ..." arg2 "arg3 ..." -flag1 arg4');
// ['arg1', 'arg2' ,'arg3 ...', 'arg4']
// ['opt1'=>'foo', 'opt2'=>'bar baz ...']
// ['flag1','flag2']

I'm planning to create two separate feature requests on github, but i would like to hear some input if such thing is welcome at all, so any feedback/idea is welcome!

edited Dec '16

Shouldn't --param be something like switch, true only, meaning do something like for example --force-clean or something, and -param contain some value ?

edited Dec '16

The example class differentiates between --: option as key+value pair and -: flag without value.

-- also means that either \s or = could be used between key and value as glue character.