TYPO3 Flows Views.yaml

In previous TYPO3 Flow distributions, rendering partials from other packages in your fluid templates was kind of tricky, as the default TemplateView of the TYPO3.Fluid package only considered the "active" package (in other words the package your current controller resides in) as a path for all template files. There are certainly use cases where one would want to store template files in another package or override just a specific partial an so forth.

Accomplishing this would have required you to write a custom View-Class and some custom render-ViewHelpers, in short a lot of additional code for such a functionality.

However TYPO3 Flow 2.1 introduced a very nice feature that allows us to define a Views.yaml, located in Configuration/Views.yaml inside a package, for overriding the TemplateViews behaviour of finding its paths in a flexible way. Here is the related forge issue: http://forge.typo3.org/issues/42176

Like in a Routes.yaml, each single configuration in the Views.yaml is separated by a "_" which stands for a sequence (array) in the YAML standard.
To generally make it possible to include Partials from a different Package, we can use the following snippet:


-
  options:
    partialRootPaths:
      'Foo.Bar/Partials': 'resource://Foo.Bar/Private/Partials'

which configures the package "Foo.Bar"s partial-path as an additional Partials-Folder for our Package, that will now be looked up by the TemplateView.
As usual, we can simply use the default render-ViewHelper to include our Partial:

<f:render partial="YourPartialName" /><br>

But keep in mind that with this configuration Fluid will now look up all available partials of the same name from the configured partialRootPaths and use the first one it finds. This can be used for simple overrides. If you are using same-named partials for different things in your configured packages and just want to _add_, not override, additional partials to your project, you would want to place the partials of one of your packages in a subfolder to prevent this from happening.

The same possibilities also apply to "layoutRootPaths" and "templateRootPaths".


-
  options:
    templateRootPaths: ['resource://Foo.Bar/Private/Templates', 'resource://Quatz.Baz/Private/Templates']   

There is a requestFilter to match your options against a specific scenario. The following configuration would override the Index.html of the default PaginateWidget from the TYPO3.Fluid-Package:


-
  requestFilter: 'isPackage("TYPO3.Fluid") && isSubPackage("ViewHelpers\Widget") && isController("Paginate") && isAction("index")'
  options:
    templatePathAndFilename: 'resource://Foo.Bar/Private/Templates/ViewHelpers/Widget/Paginate/Index.html'    

Or let's imagine we want to assign a custom View to all actions of our Foo.Bar-Package if the requested format is json. Now the setting "viewObjectName" comes into play:

The expressions used in the requestFilter are based on TYPO3.Eel and combinable with boolean operators like "||" or "&&".

A list of available expressions:

isPackage("Package.Key")
isSubPackage("SubPackage")
isController("Standard")
isAction("index")
isFormat("html")

For more information about requestFilters and their order of priority you can look at the current documentation for TYPO3 Flow 2.1:
http://docs.typo3.org/flow/TYPO3FlowDocumentation/...