TypoScript在Fluid模板中的最佳用法是什么？

Question

如果我想在 Fluid 模板中使用 TypoScript 生成菜单，有两种可能的方法：

• 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> 
  

那么，我的问题是：每种方式的优缺点是什么？
这些方法在不同版本的TYPO3中有何差异？

- Bernd Wilke πφ

Answer 1

我不同意pgampe的观点，因为这两种方法有很大的区别！

如果你使用变量，那么这些变量总是会被渲染出来，即使这些内容元素在前端没有使用。这可能会产生巨大的副作用，而且很难解决。以下是一些例子：

• 在一个未使用（或不再使用）的列中，您在页面上放置了一些重型USER_INT插件，即使它们从未显示，这些插件仍将被调用。
• 您正在使用EXT：news和ExcludeDisplayedNews功能。如果通过变量渲染了新闻插件（但从未输出），则呈现和显示的新闻插件将缺少新闻记录。

- Georg Ringer

---

我认为，每次提到dataProcessors时，都必须提及这一重要信息。这只是预渲染输出部分的副作用。我的个人建议是将繁重的渲染工作放入Fluid模板中 - 一般来说，这意味着避免使用dataProcessors，而是使用例如VHS包中的ViewHelpers或自己编写的ViewHelpers。或者只是使用旧式的TS对象，然后使用f:cObject进行渲染（它不会受到“必须预先渲染所有内容”的问题的影响）。 - Claus Due

Answer 2

您应该为所有无条件渲染或严重依赖于当前页面上下文的元素使用模板变量。

根据其他记录值进行渲染的元素最好通过视图助手使用。

从技术上讲，只要结果被缓存在页面缓存中，两种方法之间没有太大区别。这只是一个品味和可读性问题，可以选择哪种方法。

两种方法都可以使用dataProcessors返回数组或对象，在模板中可以迭代或以其他方式处理。特别是对于菜单生成，即将推出的TYPO3 8.x LTS将具有菜单处理器，它将菜单作为数组输出。请参见功能#78672（自TYPO3 8.5起包括在内）。如果您使用类似的东西，那么我建议始终将其作为变量传递。这样更清晰，不会隐藏在模板中。

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

- pgampe

---

我理解得对吗？ 页面的部分取决于当前页面的数据，应该用作模板变量。例如来自页面记录、菜单（至少在8之前）的所有数据以及来自所有列的所有内容（tt_content）。“无条件地”？语言条件或其他条件呢？您通常将它们评估为TypoScript条件吗？未缓存渲染的运行时行为是什么？我认为在模板变量而不是VH调用中使用了错误值。 - Bernd Wilke πφ

理论上，ViewHelpers 在每个环节都应该优于 TS dataProcessors，但有一个可能的例外：在系统缓存刷新后，Fluid 模板需要重新编译，这会导致第一次渲染变慢。之后，只有在实际渲染时才会执行 ViewHelpers，并且将作为纯 PHP 执行，不涉及解析。基于 dataProcessor 的设置完全无法进行这种选择性，而且会像 f:cObject 一样，不断重新执行此 TS，如果性能是您的指标，则不建议使用任何使 TS 膨胀的解决方案。 - Claus Due

这归结于您在模板化中更喜欢推送(push)还是拉取(pull)的方法。推送方法可能会导致生成过多的数据，而拉取方法往往会使模板混乱（请参见WordPress），并且难以跟踪依赖关系。 - pgampe

@ClausDue TS只被解析一次，之后只有数组的部分被传递。与IO相比，TS解析速度相当快，尽管还可以进一步提高。为了节省渲染时间，应尽可能地缓存（完整页面或页面的一部分）。然而，缓存失效可能是一个问题。 - pgampe

@pgampe 通常情况下是正确的，但对于数据处理器来说不是这样！这与普通TS非常不同，因为它仅定义了必须被处理的内容。这就是为什么我（小心地）选择了“执行”和“重新执行”而不是解析的措辞。即使如此：较大的TS意味着更高的执行时间，无论是否缓存。 - Claus Due