1
|
|
|
<?php |
2
|
|
|
declare(strict_types=1); |
3
|
|
|
namespace TYPO3Fluid\Fluid\ViewHelpers; |
4
|
|
|
|
5
|
|
|
/* |
6
|
|
|
* This file belongs to the package "TYPO3 Fluid". |
7
|
|
|
* See LICENSE.txt that was shipped with this package. |
8
|
|
|
*/ |
9
|
|
|
|
10
|
|
|
use TYPO3Fluid\Fluid\Component\ComponentInterface; |
11
|
|
|
use TYPO3Fluid\Fluid\Component\TransparentComponentInterface; |
12
|
|
|
use TYPO3Fluid\Fluid\Core\Rendering\RenderingContextInterface; |
13
|
|
|
use TYPO3Fluid\Fluid\Core\ViewHelper\AbstractViewHelper; |
14
|
|
|
|
15
|
|
|
/** |
16
|
|
|
* Makes a template extend from an Atom identified by name. |
17
|
|
|
* |
18
|
|
|
* Extending from an Atom means: |
19
|
|
|
* |
20
|
|
|
* 1) Sections from the Atom are imported to current template |
21
|
|
|
* 2) Any body content in the Atom which is *not* enclosed in |
22
|
|
|
* a section is imported at the place where this ViewHelper |
23
|
|
|
* is used. |
24
|
|
|
* 3) Sections contained within the Atom technically do not |
25
|
|
|
* exist *before* this ViewHelper is used, in terms of |
26
|
|
|
* parsing sequence (order matters). |
27
|
|
|
* 4) Any embedded documentation from the extended Atom becomes |
28
|
|
|
* the documentation for this template (but can be overwritten). |
29
|
|
|
* |
30
|
|
|
* Note that sections from the Atom can then both be extracted |
31
|
|
|
* from the template importing it, and the template can overwrite |
32
|
|
|
* any sections coming from the Atom by simply declaring a new |
33
|
|
|
* section of the same name, after the f:extends usage. |
34
|
|
|
*/ |
35
|
|
|
class ExtendViewHelper extends AbstractViewHelper implements TransparentComponentInterface |
36
|
|
|
{ |
37
|
|
|
protected $escapeOutput = false; |
38
|
|
|
|
39
|
|
|
/** |
40
|
|
|
* @var ComponentInterface|null |
41
|
|
|
*/ |
42
|
|
|
protected $atom; |
43
|
|
|
|
44
|
|
|
public function initializeArguments() |
45
|
|
|
{ |
46
|
|
|
$this->registerArgument('atom', 'string', 'Name of Atom to extend', true); |
47
|
|
|
} |
48
|
|
|
|
49
|
|
|
public function evaluate(RenderingContextInterface $renderingContext) |
50
|
|
|
{ |
51
|
|
|
return null; |
52
|
|
|
} |
53
|
|
|
|
54
|
|
|
public function onOpen(RenderingContextInterface $renderingContext): ComponentInterface |
55
|
|
|
{ |
56
|
|
|
list ($namespace, $atomName) = explode(':', $this->getArguments()->setRenderingContext($renderingContext)['atom']); |
57
|
|
|
$atom = $renderingContext->getViewHelperResolver()->resolveAtom($namespace, $atomName); |
58
|
|
|
foreach ($atom->getChildren() as $child) { |
59
|
|
|
$this->addChild($child); |
60
|
|
|
} |
61
|
|
|
$this->atom = $atom; |
62
|
|
|
return parent::onOpen($renderingContext); |
|
|
|
|
63
|
|
|
} |
64
|
|
|
|
65
|
|
|
public function getAtom(): ?ComponentInterface |
66
|
|
|
{ |
67
|
|
|
return $this->atom; |
68
|
|
|
} |
69
|
|
|
} |
70
|
|
|
|
If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.
Let’s take a look at an example:
Our function
my_function
expects aPost
object, and outputs the author of the post. The base classPost
returns a simple string and outputting a simple string will work just fine. However, the child classBlogPost
which is a sub-type ofPost
instead decided to return anobject
, and is therefore violating the SOLID principles. If aBlogPost
were passed tomy_function
, PHP would not complain, but ultimately fail when executing thestrtoupper
call in its body.