Navigation
eZ Documentation Center
 

This is outdated documentation made for eZ Publish Platform 5.2. It is being moved into the eZ Publish 5.x documentation, so please go there for most up-to-date documentation.

Skip to end of metadata
Go to start of metadata

Version compatibility

This recipe is compatible with eZ Publish 5.2 / 2013.07

Enhanced views for Content/Location

In some cases, displaying a content/location via the built-in ViewController is not sufficient and will lead you to do many sub-requests in order to access different parameters.

Typical use cases are access to:

  • Settings (either coming from ConfigResolver or ServiceContainer)
  • Current content's ContentType object
  • Current location's parent
  • Current location's children count
  • Main location and alternative locations for the current content
  • etc…

In those cases, you may want to use your own controller to display the current content/location instead of using the built-in ViewController.

Description

This feature covers 2 general use cases:

  • Lets you configure a custom controller with the configured matcher rules.
  • Lets you override the built-in view controller in a clean way.

Matching custom controllers

This is possible with the following piece of configuration:

You can point to any kind of controller supported by Symfony (including controllers as a service).

The only requirement here is that your action method has a similar signature than ViewController::viewLocation() or ViewController::viewContent() (depending on what you're matching of course). However, note that all arguments are not mandatory since Symfony is clever enough to know what to inject in your action method. Hence you're not forced to mimic the ViewController's signature strictly. For example, if you omit $layout and $params arguments, it will be still valid. Symfony will just avoid to inject them in your action method.

Original ViewController signatures

viewLocation() signature
viewContent() signature

Note

Controller selection doesn't apply to block_view since you can already use your own controller to display blocks.

Warning on caching

Using your own controller, it is your responsibility to define cache rules, like for every custom controller !

So don't forget to set cache rules and the appropriate X-Location-Id header in the returned Response object.

See built-in ViewController for more details on this.

Examples

Enriching built-in ViewController

This example shows how to use a custom controller to enrich the final configured view template. Your controller will here forward the request to the built-in ViewController with some additional parameters.

This is usually the recommended way to use a custom controller.
ezpublish.yml
Controller
article_test.html.twig

Using a custom controller to get full control

This example shows you how to configure and use your own controller to handle a location.

ezpublish.yml
Controller
custom_controller_folder.html.twig

Overriding the built-in ViewController

One other way to keep control on what is passed to the view is to use your own controller instead of the built-in ViewController.

Base ViewController being defined as a service, with a service alias, this can be easily achieved from your bundle's configuration:

Warning

Doing so will completely override the built-in ViewController! Use this at your own risk!