Study: The Presentation-Abstraction-Control architecture of TYPO3

Everybody is speaking about Model-View-Controller architecture (MVC). Has TYPO3 a MVC architecture? What do you think?

Many developers will answer this question with a clear YES. The data are in a database. Obviously there must be a model. TYPO3 generates webpages from this using HTML templates. So there is a view. Bingo. But stop. First questions pop up now:

• Having a database layer, an application-server layer and a client layer (browser) makes it a three-tier architecture. But that is not the definition of MVC.
• What exactly is the controller?
• Why do we speak of TS templates?
• Does typoscript belong to the view or is it rather the controller?

Let’s think twice. There is the file index.php, setting up the environment, reading the configuration, loading libraries, connecting the database, finally starting the rendering, caching and output of the TS tree. We can call this script the outer TYPO3 framework without counting it into MVC. If we want to fit it into MVC we should probably count it to the controller.

Having a controller now, we could call the database the model and the whole TS tree the view. The name TS template matches. Originally there were no HTML templates. All HTML was generated by TS templates. Perfect. We could take it this way.

But let’s think thrice. Let’s take a closer look into the TS tree. There are objects receiving request parameters. Typically that is a job of the controller. There are objects, that query the database. Typically that is part part of the model.

Taking TS objects into the focus we can’t state any longer, that the TS tree is the view. It’s rather a mixture of model, view and controller itself. The objects are nested. The page contains the HTML template. The template is filled with columns. The columns contain content objects. The content objects can contain extensions and each content object or extension can have functionality of model view and controller.

What holds this tree together? Most objects deliver a result string of HTML to their parent objects, strings that are finally composed to the HTML page. We discover an architecture that is hierarchically splitted into many MVC nodes, that recursively build the common nested output.

We can’t really say that each of the nodes has a clean separation of model, view and controller, but many nodes have a MVC separation. A tree of rather independent MVC nodes, that build a nested view is the definition of the Presentation-abstraction-control architecture.

All in all we can point out two different dimensions of flexibilty in TYPO3. First there is the flexibiltiy of the MVC separation. Second there is the flexibilty of nested objects configured by TS. Breaking the MVC pattern down to such a finegrained level has a price. To exchange the whole view, means to exchange it in every little node separetly. But that is a theoretical case.

The more finegrained the tree, the less advantages are in the MVC design. The more finegrained the tree, the more economic it becomes to exchange whole tree branches, instead of multiple model, view or controler parts. In practice you will exchange a whole grapical menu against a text menu, even if the model and view parts work identical and you could go by exchanging the view parts. This is probably the reason why the MVC pattern isn’t available in each leaf of the TS tree, the reason that we find some leafs of a monolithik, non MVC design, in example in form of many extensions.

Comming back to the original question, we now say that TYPO3 has not a MVC architecture of three parts. It is a tree of many nodes which can have a MVC design each. We discover that TYPO3 has mainly a PAC architecture.

Subline: TYPO3 has a mixture of different architectures. “Macro” MVC design for the HTML template. “nested micro” MVC (PAC) for almoust all TS nodes and a monolithic design in few nodes. Each architecture is used, where it matches best – or it simply depends on the taste of the developer of the given node. This mixture of architectures is one reason why TYPO3 is that mighty. It’s also one reason, why TYPO3 is that complex to understand.