Attention

TYPO3 v8 has reached its end-of-life March 31st, 2020 and is not maintained by the community anymore. Looking for a stable version? Use the version switch on the top left.

You can order Extended Long Term Support (ELTS) here: TYPO3 ELTS.

Automatic persistence of the domain logic

Remarkable at this point is, that up to this time no method to save the blogs or posts was called. Only the fact that the post is added to the blog and thereby was changed is enough to initiate extbase to save the changes permanently (to persist). Like on our first route the persistence manager is assigned with it by $persistenceManager->persistAll(). This time it collects all reconstructed objects (e.g. such, that are restored from the database) that are managed by a repository. These "managed" objects represent the root objects of an object graph (aggregate). These are so called aggregate root objects.

Note

More about the object life cycle you will find out in "Domain Driven Design" in chapter 2. The states transient and persistent are also elucidated in detail there. For the topic aggregate root you will find in the section "aggregates" in chapter 2 a detailed introduction.

The collection of new and deleted objects as well as the root objects (in our case the Blog objects) are hand over from the persistence manager to the persistence backend. The backend has the task to manage the complete process in a controlled manner. The course is done in the following order:

  • All new added aggregate root objects are inserted (first without to create the child and grandchild objects).

  • All properties of the aggregate root objects are persisted.

  • All kind objects are processed recursive in a corresponding manner.

  • All removed objects were deleted.

Warning

Do not confound the persistence backend with the storage backend that we discussed before in the section "An excursion to the database" in this chapter. The persistence backend is a layer "above" the storage backend. It is responsible for the cycle of the persistence (what should be stored, deleted or changed in which order?), while the storage backend has the job to translate the abstract requests into the native language of the "physical" storage option (most the SQL dialect of a database).

In our case the persistence backend (in the following called backend) checks for every Blog object whose properties (title, description, posts and so on) if the property values have to be stored. This is the case if the corresponding objects is new or the property value was changed in the runtime. If the property refer to an object, the backend checks in the next step also these objects for changes of the property values.

Dirty objects

How does extbase know that a property value has changed? Every object of the domain of your extension (domain object) must enhance a defined class of extbase. For the blog class this is \TYPO3\CMS\Extbase\DomainObject\AbstractEntity. Inside this parent class a property $_cleanProperties is defined. This property is directly, after the reconstruction of the object (restored from the database), initialized with the unchanged property values with a call of _memorizeCleanState(); in our case with the title, the description, the administrator and all post objects. With this it is possible later on to check every property for changes with calling of _isDirty($propertyName).

Note

All methods that starts with an underline (_) are internal methods. These methods can be called from "outside" (public) in a technical view, but they should not be called inside an extension - even though it is attractive to do that.

In our example the backend find the new post while it iterates through the post objects. The storage backend is directed to store these post in the database - and with it also all of its relations to other objects. Because the post has a 1:n relation to the blog (a blog has many posts, every post is part of just one blog) the UID of the blog is stored inside the property blog of the post. With this the post refers to its blog and can be assigned when the method indexAction() is called.

We are glad that you followed us also on this second, much more exhausting route. With the holiday destination you are so far familiar that you can move around safety in the blog example in the future without us - your travel guides. Of course there is a lot more to explore!