Well, after a while, using Phalcon, I can say that sometimes it is not so flexible when you decided to use a different approach from those that were found in the project documentation. One such case is the use of namespaces.
Several levels of the namespace are not well handled by the framework, but it is still well designed and extensible. You can redefine almost everything, and with some tweaking, you can achieve whatever behavior you want.
The following is what I did so that all my things are organized in folders / namespaces and still use the entire infrastructure.
Some of this information may be useful in your context, so here is a report of my legendary journey so far ...
Phalcon vs Namespaces
OK, therefore, if you decide to save the PHP source code within folders and namespaces, get ready to configure almost all the basic functions, and also be much more explicit in your implementations (i.e. use full class paths everywhere).
Basically, you are going to throw away some of the coolest automation that the infrastructure can offer, as they are based on conventions, and these conventions seem to be defined without using namespaces.
But, despite all this extra work, I decided to keep this design decision; In the end, we chose the MVC framework for some reason, right ?! We want everything to be organized. Especially in huge projects where it is very important that the source is diluted in several name / file spaces to improve maintainability.
Directory structure
First of all, you should know about the directory structure that I have chosen in order to understand what I am talking about below. Believe me, I spent several days days setting up this structure and reading about structures recommended by other MVC structures, and after all my personal recommendations are very simple: choose the less problematic! This usually means more loose / fragmented.
This is the structure that I am currently using that has been serving me well for almost two years and is suitable for any type of code that I need to throw at it:
A clear understanding of the structure of your directory / namespace eliminates a significant hunch when introducing new material and helps you write untied code unnoticed. If you "spend" some time caring for it at the beginning, it means that in the future you will need less painful refactors.
class loader
Did you notice the source/ folder, and its contents were organized more or less, as required by PSR Standards ? The reason for this is that the Phalcon class Loader supports PSR-0;
So basically I just need to register only the source/ folder in the bootloader:
$phLoader = new PhLoader();
... and voila! You simply reference the class (using the full path when necessary), and its internal implementations of PHP and Phalcon will find. For example, to register one of my components in a DI container:
// At the first time the service 'foo' is needed // Phalcon will read the file at 'source/MyApp/Components/Foo.php' // and then call Foo constructor $di->set('foo', 'MyApp\Components\Foo');
Routers and controllers
If all your controllers are in the same namespace / folder, you can simply do this:
$router->setDefaultNamespace('MyApp\Controllers');
Nice!
But what if you have a controller under MyApp\Controllers\Foo\BarController ?!
Like the default bootloader behavior, there is no effort from the router to try to interpret part of Foo as yet another level of namespace.
There is no workaround in ATTOW to force the router to find controllers in the “deeper” namespaces. My solution so far is to disable the default routing behavior and manually add four common patterns for each branch of the namespace .
By “four common patterns” I mean the following routes:
:namespace/index/index When only a namespace is specified
:namespace/:controller/index/ When only the namespace and controller name are specified
:namespace/:controller/:action/ When the namespace is defined, the controller and the name of the action
:namespace/:controller/:action/:params When everything is defined and includes parameters
To include these routes for all namespaces, I replaced placege :namespace regex with another regular expression that matches all possible namespaces, and implemented a "converter" that translates the route into the correct namespace (for example, "/ foo / bar / baz" → ['namespace' => 'MyApp\Controllers\Foo', 'controller' => 'bar', 'action' => 'baz'] ).
Just to illustrate what I'm talking about, here is a custom router, which I wrote some time ago, and uses this technique: https://gist.github.com/snolflake/9797835
Models
You should keep track of what the docs reports . This means that anytime you refer to a model in PHQL (or relationship definitions), you should always use the full class path.
Views
By submission, I mean mostly template files. Of course, they are not under namespaces, but since your controllers are automatic, the selection does not work properly. Therefore, your views must be selected manually:
namespace MyApp\Controllers\Foo; class BarController { public function bazAction() {
With joy, you can use the beforeExecuteRoute event to automatically select a view based on your own conventions.
Conclusion
It seems that Phalcon is more focused on a simple / trivial project, but it is completely reasonable and even with all these code templates to make your application more attractive, the rest of the structure itself makes it all come to work later.
In the meantime, I just hope there will be more name-related features in future versions.