What is the best usage of TypoScript in Fluid templates?

Question

If I want to use TypoScript like menu generation in a Fluid template I have two possible ways:

• use the TypoScript to fill a variable for the template. doing it like this:

  page.10 = FLUIDTEMPLATE
  page.10 {
      templateName = index.html
      // ... define pathes ...
      variables {
          contentMain < styles.content.get
          mainMenu < temp.mainMenu
          :
      }
  }
  

  and in the template just use the variable:

  <div class="header">
      <div class="logo">{logo->f:format.raw()}</div>
      <div class="main-menu">{mainMenu->f:format.raw()}</div>
  </div> 
  

• the other way is the usage of the f:cObject ViewHelper to call a part of TypoScript.
  the TypoScript:

  page.10 = FLUIDTEMPLATE
  page.10 {
      templateName = index.html
      // ... define pathes ...
      variables {
          contentMain < styles.content.get
          :
      }
  }
  lib.mainMenu < temp.mainMenu
  

  while the Fluid template looks like this:

  <div class="header">
      <div class="logo">{logo->f:format.raw()}</div>
      <div class="main-menu">
          <f:cObject typoscriptObjectPath="lib.mainMenu />
      </div>
  </div> 
  

so. My question: what are the pros and cons of each way?
Are there differences for the different versions of TYPO3?

Tragedy

Answer 1

I disagree on the opinion of pgampe as there are big differences regarding those 2 approaches!

If you are using variables, those are always rendered, even though those content elements are not used in the frontend. This can have huge side effects which are really hard to tackle. Some examples

• You have some heavy USER_INT plugins on a page in a column which is not in use (anymore). those will be still called even though they are never shown
• You are using EXT:news and the feature ExcludeDisplayedNews. If there is a news plugin rendered somehow via variables (but never outputted), a news plugin which is rendered and shown will miss news records

Tenace

This piece of information is, I think, vital to mention every time dataProcessors are mentioned. It is, quite simply, a side effect of pre-rendering output parts. My personal advise would be to stick the heavy rendering into the Fluid templates - generally speaking, this means avoiding dataProcessors and using ViewHelpers from for example the VHS package, or ones you write yourself. Or just old-school TS objects you then render with f:cObject (which does not suffer from the "must render everything beforehand" problem). – Respectability

Answer 2

You should use template variables for all elements that are rendered unconditionally or heavily depend on the current page context.

Elements that are rendered depending on other records values are better used via the cObject viewhelper.

Technically there is not much difference as long as the result is cached in the page cache. It is only a matter of taste and readability which method to prefer.

The both method can use dataProcessors to return arrays or objects that can be iterated or otherwise processed in the template. Especially for menu generation, the upcoming TYPO3 8.x LTS will have a menu processor that spits out the menu as array. See feature #78672 (included since TYPO3 8.5). If you use something like that, then I suggest to always pass it as variable. This makes it much more clear and does not hide it in the template.

https://docs.typo3.org/typo3cms/extensions/core/8-dev/Changelog/8.5/Feature-78672-IntroduceFluidDataProcessorForMenus.html

Ulane

do I get you right? the parts of the page, which depends on data of the current page should be used as template variables. e.g. all data from pages record, menus (at least prior to 8), and all content (tt_content) from all columns. 'unconditionally'? what about language condition or other conditions you normaly evaluate as typoscript conditions? what is the runtime behaviour for uncached rendering? I assume bad values for VH-calls instead of templates variables. – Cliffcliffes

Theoretically, ViewHelpers should outperform TS dataProcessors at every turn with one possible exception: after a system cache flush, Fluid templates need to be recompiled which causes a slowdown on the very first rendering. After which ViewHelpers will execute only when they're actually rendered and will execute as straight PHP, no parsing involved. A dataProcessor-based setup is wholly incapable of this selectivity and will, correct me if I'm wrong, re-execute this TS constantly, as would f:cObject. If performance is your metric then any solution which bloats TS is not recommended. – Respectability

It comes down to whether you prefer a push or a pull approach in templating. The push approach likely results in too much data being generated, whereas the pull approach tends to clutter (see wordpress) the template and makes it hard to track dependencies. – Ulane

@ClausDue TS is only parsed once, afterwards only parts of the array are passed around. Compared to IO, TS parsing is rather fast, although it could be made faster. To save render time, you should cache as much as possible (full pages, part of pages). Cache invalidation can be a problem though. – Ulane

@Ulane that is usually correct, but not in the case of dataProcessors! This works very differently from normal TS because it only defines what must be processed. That is why I (carefully) chose the wording "execute" and "re-execute" rather than parse. Even so: a larger TS means higher execution time regardless of caching. – Respectability