Continuation of MVPC – the difference between Presenter and Controller
Nette and MVPC
Nette is taken here as an example of a PHP web application framework I am the most familiar with. The same might or might not apply to any other framework in PHP or any other language.
Nette framework is my web framework of choice. There are a few reasons for it, the most important are security by default and completely ready co AJAXful websites. But the most important feature of Nette for me, the one that makes it really fit into the MVPC design pattern, is its dependency injection container. But first let's talk about the building blocks of Nette and how they fit into MVPC.
There are many ways how to measure what are the most prominent or most important parts of a framework. However Nette makes it easy for us. It is decomposed into several individual packages (each of which you can use on its own), and by combining them together with the help of several bridges, you get the whole framework. Therefore we can look what are the most prominent packages that compose the framework. So I looked at the landing page of Nette Framework (2016–04–22) and there it was, four main components right in the homepage: Framework, Tracy, Latte, Tester. Just to be sure I then checked packagist and there were only 2 packages not using nette as vendor. Those were tracy/tracy and latte/latte. So big they have its own vendor? They must be prominent then, lets look at them.
Tracy is a debbugging tool from another world. There is nothing like it. For me personally, there are two main components to Tracy – BlueScreen and Debug panel. Every one of us experienced the imfamous windows BSOD. In Tracy, when something goes wrong, you won't get the awful PHP default error message, that is completely useless, but rather a very useful HTML page with all the detail you need to debug the problem. And the debug panel is invaluable when debugging live application and can only barely be matched by Symfony Web Debug Toolbar. But Tracy is solving a cross cutting concern in the application and obviously has nothing to do with the MVPC pattern, so let's move on.
Latte is a templating engine and as such it obviously fulfills the role of the view in MVPC. However if you look at it closely, you will find out, that in the linux fashing, it can do only one thing and do it very well. But only one thing. It can render HTML/XML files. To the output, to a variable, to a file, it can do it all, but it can only do HTML/XML. And that is a major problem. As I mentioned in previous article, you application migh want to sent response to the console or maybe in API to another application. You could make an SOAP API and send XML documents, but you vill have a problem generating JSON files for your REST API. And you will hardly be able to output to the console. So Latte is a great view, but only for one particular type of response. It is great if used in a website, where the response is the HTML for the browser to parse and display.
So what is left of the framework? We discussed Tracy and Latte and will skip Tester, because that is obviously soething you don't use in your production code. What we are left with is a set of packages, all of which are a dependency of a package „nette/nette“. The core of the framework, a collection you will get if you install the framework. The part having all the
So what does this package really contain? Well as I said, it has a lot of really useful functionality. There is the DI Container, different caches, PHP tokenizer, atomic access to files etc. But there are a few packages, that are really dependent on the type of request recieved. Packages like
Application are really banking on the fact, that all you requests will be HTTP as well as the responses. And what more, they are really preoptimized for request made by a browser while browsing a website. That is not to say, that other requests are impossible. There has been a lot of hard work into implementing CLI and REST routers and JSON responses. But it is not easy and you have to bend the framework a bit. The main problem is with the
Forms. It is obvious why the forms package would not be sutable for API, so let's rather take a closer look at the Application and HTTP packages.
Nette Application and HTTP
If you thought the HTTP package is unsuitable, the Application is much worse. It is enough to look at the class names in the package. Templates? States? Forms? What is this nonsence? I don't nee any of this for my REST API. And in the Presenter class – templates again? AJAX rendering? How can API have AJAX? Flash session? But I can have no session. Argh!
And what about the model in Nette? Well, Nette does not solve this issue for you by default. Id gives you total freedom in the model layer to use. You might suffice with dibi, possibly with leanMapper, or you might opt in for NotORM or Doctrine. The choice is yours.
Putting it together
So does it mean Nette is bad framework? And if so, why am I using it?
Nette is a great framework as I said in the very beginning. There has been one application where I have not complained about Nette at all. Nette is great for a website. It is designed and built specifically to fullfil that need. To make a very secure, AJAX friendly website. But it is not great for building an API. However APIs and websites often coexist in the same application. How to solve this disparity will be the topic of the next article.
Continues by MVPC – Deeper look