Reason #4 for Choosing TYPO3: Object-oriented Architecture

TYPO3 isn't all about features. Features are important, of course, but the underlying architecture of a CMS is also important because the architecture is what determines both how much developers can accomplish with plug-ins and extensions as well as how scalable those extensions will be over time. The argument of this post is that TYPO3 is fundamentally different from other popular CMS solutions because of its object-oriented architecture, and that this distinction makes TYPO3 more scalable and significantly more powerful. I'm going to compare Wordpress's hook based API to TYPO3's object oriented API in order to highlight the consequences of each platform's architectural choices.

Let's start by looking at how templates are approached in Wordpress and comparing it to how TYPO3 handles templates. Wordpress themes are mostly composed of HTML with PHP function calls where dynamic content needs to be included. Unlike many developers, I'm not against PHP templates on principle, however, there are clear and obvious shortcomings to this approach. For one, with the wordpress approach to theming, we immediately give up on any true separation of business logic and presentation logic. Not the end of the world, perhaps, but a clear limitation insofar as presentational changes to themes can affect programatic logic and introduce errors. Moreover, the presentation layer (HTML, CSS, JS) can no longer be treated as a self-contained set of XHTML files that can be validated and tested outside the context of the CMS. PHP templates also fail to restrict developers in what they can and can't do; if the developer working on them needs access to a record in the database, there's no reason why they can't query the database directly from a theme or, for that matter, access unsanitized GET and POST variables. I tend to see this as an architectural short-coming; architecture should encourage and enforce best practices, not simply trust that developers will follow them.

TYPO3, on the other hand, takes a completely different approach to implementing site templates. All templates in TYPO3 are pure XHTML/CSS. For us, this means that we can deliver comps to frontend developers who can in turn produce templates without any knowledge of TYPO3. The base markup for the presentation layer is stored in XHTML files where it belongs, and then mapped to back-end interfaces and content areas. This separation allows us to more easily break down a project and to have different team members working on the frontend and the backend at the same time. Moreover, we don't need to worry about frontend developers following backend best practices. Templates aren't executed directly as PHP files, rather they are parsed and pulled into the CMS so that content can be mapped onto them before the page is rendered. Moreover, TYPO3 treats each component on the page as an object (more specifically, as a Typoscript object).

Folks sometimes complain that Typoscript is too complicated or too difficult to learn. It's not. Most of the concepts of Typoscript are pretty simple and, if explained correctly, we see new developers picking it up quickly and without too much trouble. Put simply, the main idea of Typoscript is this: each bit of content on a page is a Typoscript object. This includes elements that stay the same on every page of the site (for example: navigation, header search input, footer navigation, logo in the header, etc) as well as elements that change on each page of the site (such as content elements, which are also simple Typoscript objects of the type "RECORDS"). These objects are self-contained, and they don't interact with each other. They are rendered independently of each other, not via hook call in a PHP file, but through CMS logic that governs how records are rendered. Because these objects are self-contained and encapsulated, they can be copied, reused, and extended, as is the case with objects in code. For example, if a client has a sidebar box of links that contains different links on each branch of the site, all we need to do is create a Typoscript object that renders the navigation and then sent constants on a branch-by-branch basis telling the object what pages it should contain. This sounds trivial, but it's an important illustration of how TYPO3's commitment to object-oriented architecture (both in terms of code and in terms of the concepts built into the CMS) simplifies the developer's job and provides significantly more extensibility than a hook-based architecture.

We can also look at how Wordpress implements plug-ins compared to how TYPO3 implements plug-ins. The plug-in API in the wordpress codex makes it clear that Wordpress' architecture is entirely hook based. Indeed, Wordpress offers two kinds of hooks into their system: actions and filters. According to Adam Brown, there are 1,344 hook calls in the most recent version of Wordpress. Now, some of you may think that 1,344 hooks is a wise architectural choice, but I want to encourage you to question that belief a bit. First off, it means that as the developer you're completely at the mercy of Wordpress when it comes to figuring out where your code can be called. With that many hooks, I suspect developers can find the hook they need in most cases. Nonetheless, it's still a limiting factor; you can only execute code where the hook already exists. The second problem I see with this approach is that it leads to code that is fundamentally unmaintainable. I'd much rather see an API in which custom objects were instantiated, initialized, and executed at clearly defined points throughout the page rendering process instead of an API that is constantly checking for hook calls during execution. In the former, the execution of an object is self-contained and encapsulated.

TYPO3 takes a totally different approach than that of Wordpress. Take a plugin, for example. Plugins are, like all other content on a page, an instance of a Typoscript content object. As TYPO3 loops through the content on a page, it finds an element that is a plugin. Let's say, for the sake of argument, that it's a list of blog posts coming from a blog extension. TYPO3 goes to the extension directory and looks for the main PHP script that represents that plugin. That script contains a PHP class that extends a core TYPO3 class for extensions. The class is instantiated into an object, and TYPO3 calls a function called "main" in the object. This is TYPO3's single input into the plugin, which is completely encapsulated from the rest of TYPO3. Sure, it has access to configuration and various global variables within TYPO3, as well as a number of distinct APIs (for database queries, image generation, content rendering, and so on and so forth), but it's not going to be repeatedly called as the CMS executes the request. Because the interface between TYPO3 and the plug-in is simple (one class is included, one object is instantiated, and one public method on the object is called), updated versions of TYPO3 tend not to break plug-ins. That key interface is simple enough where it never needs to change. But, it's also powerful enough where plug-in developers can do just about anything they need to within the context of their plugin. For example, we've written our own MVC framework on top of TYPO3's base plugin class (piBase), something that just wouldn't be possible with a hook-based system. Nowadays there is ExtBase, which is a backport of FLOW3's MVC components into TYPO3. These sorts of implementations are possible because TYPO3 has a clean plugin interface as well as numerous distinct APIs for other parts of the system. Implementing something like this in Wordpress in a way that was future-proof and scalable would be incredibly difficult because the hook-based API is just too massive and too open for that to be easily possible.

Hooks aren't all bad, of course. TYPO3 has a number of hooks in the core. It's possible to go too far with object-oriented architecture and make every component extensible (I'm looking at you, Magento!), which can be a problem in it's own right. Hooks are good; hooks help developers execute code in unexpected places and modify data as it's being handled by the CMS. What I object to is an architecture that is entirely hook-based. This kind of architecture is too rigid, too complex, and too indicative of brittle, procedural code.

I started working with TYPO3 before PHP5 adoption was widespread and most PHP applications were still pretty procedural. This was six or seven years ago, and we've come a long ways since then. TYPO3 was lucky because while there are procedural components of the platform, it's significantly more object-oriented than most systems that were born around the same time. These days, I think it's safe to say that nobody would make the architectural choices that Wordpress made early on. PHP5 has provided such a solid foundation for writing object-oriented code, I don't think any professional PHP developer seriously consider writing a CMS these days using a procedural approach. Procedural code is inflexible, difficult to maintain, and for these reasons is fundamentally not suited to agile development. TYPO3, for all its faults, was smart to move towards object-oriented architecture in a time when many in the PHP world hadn't really got on board. If I were looking for a CMS and considering Wordpress (or Drupal, which is also hook-based and largely procedural, last I checked) as a viable solution, I would think long and hard about how much customization I planned on doing. Brochure sites that use a handful of plug-ins can be well served by Wordpress, which has an awesome backend interface and is a strong implementation of many blog concepts. However, if I were thinking about a larger project with a number of custom pieces, I would have to think long and hard about whether it is wise to develop significant code on top of a procedural, hook-based architecture.