Which template system should I use in Typo3?

Question

Up to now, I used to use template auto-parser. I like the fact I can modify any element of the template using typoscript, without altering the initial HTML file. I also like the fact that I can render the html template directly in a web browser, filling it with dummy elements to see examples of menus and content elements. Finally, with the new backend templates, i now can place content elements anywhere on a grid, in a way that mimics the real aspect of the website.

I know there is also TemplaVoila. I never took the time to learn it. My feeling is that it is less compatible with some extensions, but maybe I am wrong.

Now, there is fluid, that will be used in the next version of Typo3. While it is clear that it is better using it that using template markers, I don't really understand why I should be better using Fluid than using template auto-parser or TemplaVoila. What I dislike is the fact it requires to modify the html template with special tags, meaning that either the web designer has to know Fluid, or the Typo3 integrator has to modify templates from the designer each time a modification is performed.

My question is: should I migrate form template auto-parser to Fluid for my website template? What are the benefits of using Fluid? Why should it be better? What template system should I use with Typo3?

Answer 1

As long as TypoScript does not support objects, the benefits of FLUIDTEMPLATE over template auto-parser are only a few. So there is no need to migrate.

But IMHO there are some arguments to switch to fluid:

• more and more extensions will use fluid, so it will help you to learn fluid
• you can use an ide with code-completion for fluid (it is just XML!)
• fluid is really powerfull, you can have f.e. if statements which checks for empty content
• some day TypoScript will support objects as well

But for extension developement, it is totally different. In an Extension, i would allways prefere using FLUID. You do not have to deal with template things inside your extension anymore. Just pass the data to fluid and things which concern the view will be done in your template.

Answer 2

Whever you choose, it should be something based on Fluid - this will allow you to be extremely versatile and it makes the implementation less important than the template, which is quite good.

I myself am the creator of the "Fluid Powered TYPO3" framework (formerly known as FED) and would of course recommend that you take a look at what this framework can do for you - it's capable of great things, not the least of which is saving you a lot of time while at the same time allowing you to create even more consistent templating for pages and content - and even backend modules.

And we're always happy to help new users. We are currently in the process of improving our documentation, but you can already find many fully up-to-date guides on our Github page - https://github.com/FluidTYPO3 - the repository called "documentation" is the place we will store all the documentation.

You may want to have a look at http://fedext.net http://fluidtypo3.org - especially the "Tour of features" which tries to explain the point of Fluid Powered TYPO3 in as few words as possible. After that, the examples from the documentation will give you a much clearer picture of what Fluid Powered TYPO3 can do for you.

We focus on efficiency always - we've tried to do all the heavy lifting so that you really can just sit down and begin creating page templates. We took a lot of inspiration from TemplaVoila but there is no more re-mapping of content and things like this: when you change your templates, that change is immediately reflected, which makes it very nice to work with in iterations and do things like continuous delivery and -integration.

Hopefully this helps!

Cheers,
Claus aka. NamelessCoder

Answer 3

You could also argue, that adding special tags like

<f:section name="typo-content">
   <div id="content">This is where the designer intended content to go</<div>
</f:section>

Could assist your designer while doing a redesign to know where you "mapped" your content elements to. This is neither the case with autoparser nor with TemplaVoila. So if the designer moves stuff around you probably get your templates back and they still work without any modifications.