Feature #67890

Redesign FluidTemplateDataProcessorInterface

Added by Patrick Broens over 6 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2015-07-02
Due date:
% Done:

100%

Estimated time:
PHP Version:
Tags:
Complexity:
easy
Sprint Focus:

Description

Currently the method process in FluidTemplateDataProcessorInterface looks like

public function process(
    array &$data, // $this->cObj->data
    array $processorConfiguration,
    array $configuration,
    StandaloneView $view
);

where $data is $this->cObj->data coming from FluidTemplateContentObject.

There are two issues with this:

1) The data processors currently written and in review are instantiating the ContentObjectRenderer ($this->cObj) again. This is overkill, since it is already available in FluidTemplateContentObject.

2) This variable is referenced, which makes it possible to influence $this->cObj->data. It is better to assign manipulated values to the view directly, instead of using $cObj->data. As an example: {data.bullets} should contain the non-manipulated data, {bullets} should contain the manipulated data.

3) The table name is desired in the data processors.

The proposal is to use $this->cObj from FluidTemplateContentObject in the method process of FluidTemplateDataProcessorInterface, like

public function process(
    array $cObj, // $this->cObj
    array $processorConfiguration,
    array $configuration,
    StandaloneView $view
);

This is breaking since we introduced the interface in version 7.3.0


Related issues

Related to TYPO3 Core - Feature #66907: Add possibility to the FLUIDTEMPLATE Content Object to do data processing before renderingClosedPatrick Broens2015-05-12

Actions
Related to TYPO3 Core - Task #68762: Document DataProcessorInterface for Fluid TemplateClosed2015-08-05

Actions

Also available in: Atom PDF