Robert Lemke

TypoScript in TYPO3 Phoenix

Published on 05.05.2010 by Robert 10 comments
Filed under: TYPO3

We have passed the first half of our first official TYPO3 Phoenix sprint and the sprint goal - to render a simple website - becomes more real every day. One part I've been working on quite intensively during the last days is the TypoScript rendering. To give you some impression of what you can expect from the next generation of TypoScript I'd like to start some loose series of blog posts about it.

Before I get down to the nitty-gritty, let me loose some words about the design goals of TypoScript II. And let me warn you: This might sound like a advertising brochure because I'm so consumed by this topic at the moment. So, the most important design goals I can remember right now were:

• Clear Purpose
• Consistency
• Object-Oriented
• Extensible

The clear purpose is supposed to help especially newbies to classify TypoScript in the world of markup languages they might know already.

TypoScript II is an object-oriented view configuration syntax

This means that we use TypoScript for selecting and processing the content we'd like to display on our website or in some other format. TypoScript won't be used for settings or pure configuration not related to the view - no more "Page TSconfig". This kind of usage caused a lot of confusion in the past and will be replaced by a combination of YAML and user interface controlled settings.

Consistency is what I've personally been longing for for years. Why does this property support stdWrap and the other doesn't? Why are there two properties "height" and "width" while another object uses "dim" (dimensions)? Is there life beyond option split?

We solved this by making TypoScript truly object-oriented. Each TypoScript object is implemented by a real PHP class which makes it possible to inherit certain common aspects from other objects. The probably nicest feature in that regard is the processors mechanism (I'l cover them in detail in a later post). Processors are basically stdWrap on steroids - they can be chained, put into a certain order, used multiple times on the same property and - most importantly - exist for any TypoScript Object property. There's no need for extension authors to support them explicitly, they are just there.

Object-orientendness also means that TypoScript goes pretty well with other PHP objects, such as Domain Models. We adhere to the clean approach we've taken for FLOW3 so you're able to display any PHP object by means of TypoScript.

Your favorite TypoScript object is not in the official TYPO3 distribution? No problem, because you can very easily create your own. And even better: you can override behavior of existing TypoScript objects, including the "built-in" objects provided by TYPO3, if you need to. Because TypoScript supports namespaces, you can even switch from one Page object implementation to another by just switching the namespace. And because each TypoScript object is based on a Fluid template you have full control over the HTML output if you want to.

Okay, before I end this working day now, here's one detail you might like if you're a fan of systems like Subversion or Git (and if you're not, you're not really a developer, are you?): TypoScript configuration is file-based by default - there's even no need to anchor it or reference to it from pages within your page tree. As long as the directory structure match that of the page tree, TS templates are mounted into the right place automatically. And because of that you can put your whole website, including all of its assets, into a FLOW3 package. But that's another story for somewhere along the way ...

What do you miss most with the current TypoScript syntax? And what's your favorite feature?

Robert is TYPO3 5.0 and FLOW3 founding dev, espresso lover, hopeless optimist and proud father.

Recent Posts

• TYPO3 Phoenix, Aloha and the AGPL license
• Session Handling and Object Serialization
• Paper Selection Process for T3CON10
• MacBook Pro in den USA kaufen?
• TypoScript in TYPO3 Phoenix