Phalcon\Cli\Console and Namespace support

Firt of all this is a long post and it's something that I sould be contributing (make it myself and share) but well, maybe someone else did it, it's pending, or Im doing things the way I'm not suposed to.

Long short story, I need to use Phalcon\Cli\Console with namespaces on a nice orderly module integrated fassion.

So, here it goes:

I'm developing a multi module, multi mode (MVC/Console) Application.

I'm currently having two modules named "base" and "billing".

The base module is for the MVC Application only and the billing module is to be used by both MVC and Console Applications.

To get the two of them working "together" as you don't have a unified instance of Application that handles both things, I've implemented a builder pattern to “build” one or another as follows:

ApplicationBuilder: parent class, has three methods that implements and to be implemented as well for it's children; one to register services, another to register the loaders and the last one is an initialization method. Here is the definition of all the common modules, services and loaders required for both applications. It registers i.e. the logger, database, billing module, etc. There is another method called “build" (the only public) that returns the specialized instance of Phalcon\Application (by it’s children).

MicroBuilder: hey, if I want to add a Micro Application, I can do it by implementing this.

The idea of implementing the builder pattern here is to delegate the complex building (setting services, loaders, modules and configurations) to a model that you have all the applications together and sharing their components; i.e. if I want to change the Phalcon\Logger\Adapter service to all the applications I only need to change it on the registerServices() method of ApplicationBuilder. You get the idea…

So everything is "nice" and "mostly happy" tied together until I get the following setback:

The framework is not properly adjusted to be working with Console Applications and Namespaces.

Phalcon\Cli\Console->handle requires an array and basically it sends the arguments to Phalcon\Cli\Router->handle
phalcon/cli/console.zep#L63 and then sets the dispatcher, etc.

Phalcon\Cli\Router\Route->reConfigure executed by it’s constructor it does correctly support namespaces
router/route.zep#L89

So if we call Phalcon\Cli\Console->handle with an array it doesn’t work with namespaces.

If we declare a specific route like “billing/:controller/:action” we can match it to i.e.[“module” => “billing”, “namespace” => “My\Billing\Module\TaskNamespace”, “controller” => 1, “action” => 2] it will no be processed by the router as this will require to call Phalcon\Cli\Console->handle(“billing/:controller/:action”) that we cannot do.

The only thing to do that works out of the box without getting much into trouble is to specify the namespace on the task argument i.e.

The Phalcon\Cli\Router should add namespace support by adding it to it’s default routes, adding a _defaultNamespace property, _namespace property, it’s access methods, and make it work with arrays (with strings it already works as Phalcon\Cli\Router\Route does support them properly)

The Phalcon\Cli\Console->handle:

Should set the namespace on the dispatcher as Phalcon\Cli\Dispatcher already supports namespaces as they are implemented on it’s parent.

Thanks for the sugestion, I few months I've learn about this framework and the first thing I did before even write a line or install the module was to read about phalcon that lead me to zephyr, then I read about zephyr and learn it's basics.

I'm on my fourth phalcon application and I've been looking directly into the zep code to find some things that may or may not be on the web docs of phalcon but sometimes it's easier to see how it's made.

I've never (ever) contribute directly on a open source comunity and since I mainly work on enterprise environment, I never (ever) used GIT for source control (I use svn). So first I need to get in touch with GIT. Furthermore, I need to learn how compile the source zeps into the phalcon zep to build the module for testing purposes etc. And... shame on me, I've never wrote test cases before.. so it's a lot of to-learn checks before I adventure into posting a PR.