The book about Extbase and Fluid was written in close collaboration with Sebastian Kurfürst (core developer of Fluid) and Inken Kiupel (reader). We hope that it encourages the developers of TYPO3 extensions to get in touch with the fascinating concepts of FLOW3. And we hope that the book eases the migration to TYPO3 v5 (that’s what Extbase is all about).

We are aware of the fact that many of the English speaking TYPO3 developers are eagerly waiting for more Books about Extbase and Fluid published in English. Sebastian Kurfürst and I are currently investigating the best way to to get the book translated into English to be published on typo3.org.

If you have any questions regarding the book, or found some typos (at least 3), feel free to use the comments facility (if it is positive ;-) ) or write me an e-mail. I am really looking forward to hear from you.

You might want to support our work by ordering the book through this link.

The past couple of months I had numerous discussions about the new version and how to migrate from TYPO3 v4 to v5. And I had to realize that there are several reservations and concerns about all the new things to learn. All of them have to be taken into account to keep the community healthy.

The people I have talked with had different backgrounds (different knowledge about TYPO3, different involvement in the community, etc.). Most of them asked one of the following questions:

1. When will TYPO3 v5 be available?
2. How to migrate content?
3. How to migrate code (extensions)?
4. How to migrate me?

Questions 1.-3. are already covered by an article of the v5 team. The most underestimated question is, how to cope with the mental transition of the developers. Many developers pointed out that they do not have enough time to dig into the new version. Maybe that is a question of how to weight the time spent on daily business and the time spent on (self) education. This prioritization has to be done not only by the developer himself but also by the company he is working for. Therefore, many of the developers decided to wait until FLOW3/TYPO3 v5 is released at a future point in time.

To enable the developers to get in touch with the paradigms of FLOW3 as soon as possible was my personal motivation to be involved in doing a back-port of the  FLOW3 [MVC|MVC stands for Model-View-Controller, a way to separate different concerns of an application] frame-work. The result is ExtBase, a new frame-work for extensions and a successor of [pi_Base|The standard Plugin Base Class of TYPO3 v4]. It will be shipped with TYPO3 v4.3. It is planned to be released in May, 2009.

Furthermore, I am very happy about the decision at the TYPO3 snowboard tour to back-port Fluid, too. Fluid is a very sophisticated new templating engine mainly developed by Sebastian Kurfürst.

ExtBase in companion with Fluid encourages the developer of TYPO3 v4 based extensions to code the FLOW3 style right now.  There is already an example extension called BlogExample available. At time of the release of v4.3 we also plan to give a good documentation at hand.

Although we implemented already 80% of the features there is quite a lot of work to do (e.g. implementing view helper classes, doing code reviews, and integration testing, writing documentation and tutorials). Do not hesitate to send me a message, if you want to lend us a helping hand.

Domain-driven design (DDD) is an approach to the design of software, based on the two premises that complex domain designs should be based on a model, and that, for most software projects, the primary focus should be on the domain and domain logic [...].

The domain represents structure, knowledge and data. A content management system (CMS) like TYPO3 has to handle the data of the domain with respect to the domain knowledge. It aggregates the data, and visualizes it as a content of an output format.

A question emerges: How should the data stored in a domain be mapped on the content of the output? You might say: “Hey, what’s the problem? The data ‘stored’ in the extension is already the content to be displayed!”. I don’t think so. Nowadays, the domain of an extension and the domain of the CMS are woven into another. And the following questions are answered by the extension itself:

• “What is the title of the article?”
• “How many articles should be shown on the front-page?
• “Should the subtitle of the article be emphasized?”

So, we have to spend hours and hours to adapt all the templates of an extension to fit in the overall context of a web page. That’s annoying. Now, let’s try to solve that issue. The first thing is to assign the questions to the proper domain:

• “What is the title of the article?” → domain of the extension
• “How many articles should be shown on the front-page? → domain of the CMS
• “Should the subtitle of the article be emphasized?” → domain of the CMS

If we finished the separation of the two domains we are ready to take the next step: mapping the domain of the extension onto the output generated by the CMS. I propose a two-step process:

1. Map the domain objects of the extension onto the content object aggregate of the CMS
2. Transform the content object aggregate to the output format

The first step maps the domain objects of the extension onto content objects. These aggregated content objects represent the structure and the semantics of the output, but not its syntax (like “<h1>The Title</h1>”). The second step transforms the content objects to the output format. This can be done with a templating engine as usual.

The benefit of this two-step process is that the CMS “owns” the templates. So we can configure the visual representation of the domain objects of all extensions at one central place.

An Example

An example might clarify the process. Let’s assume I want to write a news extension. The first step is to design the domain of my new extension:

The domain model "News Item" of the extension

Then I have to examine, what the CMS built-in content object catalog offers to me. Hm, okay, there is already a content object called “article”. It seems to fit my purposes:

The domain model "Article" of the CMS

I configure the mapping as follows:

• Author → Author
• Text  → Text
• Title → Header
• Subtitle → Subheader
• Teaser → ShortDescription
• PublishingDate → Date

As a result, I have a generic “Article Object” which can be added to a higher-level content object, like “Main Content Area” or “Page”. My “News Item” will be rendered depending on the configuration of the transformation process and the context the article is displayed in. I—as an extension developer—don’t have to deal with the visualization of my domain objects.

But, what if I want to get the control back over the presentation of my domain object? Then I have to define my own content object class (which can of course extend an existing content object class).

This leads to much more decoupled way of content management based on domain driven design. That’s why I called it “Domain Driven Content Management”.

I’m anxious to read your comments.

1. collect clients’ or personal needs
2. design the relational model (database design)
3. scaffold the extension using the kickstarter
4. add a lot of database queries template handling to the file _pi1, _pi2, _pi3 etc.
5. design the templates

This ends up in an extension design which is hard to maintain – especially for larger projects. A more modern approach uses the Model View Controller Pattern. One of the advantages of this pattern is to enable the developer to focus on the domain of the client (and thus the domain model of the extension). So, the MVC pattern is a prerequisite for Domain Driven Design. This leads to a slightly different development process:

1. collect clients or personal needs
2. design the domain model (classes) translating the domain knowledge of the client into UML
3. scaffolding the extension using a kickstarter
4. adding the business logic to the domain model classes
5. design the templates

What are the pros of this approach

• The developer and the client use a common language.
• The domain model is more decoupled from the implementation architecture.
• It’s clearly defined where the business logic resides (in the domain model classes).

… and the cons

• It adds complexity to the extension.
• It forces the developer to learn new programing paradigms, which might be difficult to schedule in the daily work.

To be consequent we have to go one step further. The domain knowledge is captured in natural language. But natural language is much more expressive than object oriented software design in UML. As a consequence, there is a mismatch between the domain model expressed by the domain experts (the client) and the object oriented model expressed in UML.

If we want to keep all the information of the domain experts we have to define an ontology. To express the domain knowledge in an ontology, OWL seems to be a good solution to me, as it is a W3C standard and targets web applications. To edit ontologies I played around with Protégé.

In the end, we will have a process which can be named “Ontology Driven Extension Development Process”:

1. collect clients or personal needs
2. design the ontology using the same language as the client does
3. scaffolding the extension using a new ontology driven kickstarter
4. adding the business logic to the domain model classes
5. design the templates

What are the pros of this approach

• The developer and the client use a common language.
• The ontology based domain model is independent from the implementation and can be shared across different extensions with different purposes.

… and the cons

• It adds complexity to the development processes.
• It’s forces the developer to learn completely new paradigms an terms.

I’m looking forward to your comments an appreciate any questions.