Completed
Pull Request — master (#470)
by Claus
01:35
created

HtmlViewHelper::allowUndeclaredArgument()   A

Complexity

Conditions 1
Paths 1

Size

Total Lines 4

Duplication

Lines 0
Ratio 0 %

Importance

Changes 0
Metric Value
cc 1
nc 1
nop 1
dl 0
loc 4
rs 10
c 0
b 0
f 0
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
use TYPO3Fluid\Fluid\Core\ViewHelper\TagBuilder;
15
16
/**
17
 * HTML container tag ViewHelper
18
 *
19
 * Intended for use as aliased ViewHelper so that <html>
20
 * tags will be handled by this ViewHelper class. Allows
21
 * Fluid to extract namespaces from <html> tags and if
22
 * so instructed, not render the <html> tag itself but
23
 * only the child content.
24
 */
25
class HtmlViewHelper extends AbstractViewHelper implements TransparentComponentInterface
26
{
27
    protected $escapeOutput = false;
28
29
    protected $escapeChildren = true;
30
31
    protected $shouldRenderTag = true;
32
33
    protected $namespaces = [];
34
35
    public function onOpen(RenderingContextInterface $renderingContext): ComponentInterface
36
    {
37
        $arguments = $this->getArguments()->getArrayCopy();
38
        $resolver = $renderingContext->getViewHelperResolver();
39
        foreach ($this->arguments as $name => $value) {
0 ignored issues
show
Bug introduced by
The expression $this->arguments of type object<TYPO3Fluid\Fluid\...rgumentCollection>|null is not guaranteed to be traversable. How about adding an additional type check?

There are different options of fixing this problem.

  1. If you want to be on the safe side, you can add an additional type-check:

    $collection = json_decode($data, true);
    if ( ! is_array($collection)) {
        throw new \RuntimeException('$collection must be an array.');
    }
    
    foreach ($collection as $item) { /** ... */ }
    
  2. If you are sure that the expression is traversable, you might want to add a doc comment cast to improve IDE auto-completion and static analysis:

    /** @var array $collection */
    $collection = json_decode($data, true);
    
    foreach ($collection as $item) { /** .. */ }
    
  3. Mark the issue as a false-positive: Just hover the remove button, in the top-right corner of this issue for more options.

Loading history...
40
            if ($name === 'data-namespace-typo3-fluid') {
41
                $this->shouldRenderTag = $value !== 'true';
42
                $this->arguments['data-namespace-typo3-fluid'] = null;
43
                continue;
44
            }
45
46
            $parts = explode(':', $name);
47
            if ($parts[0] === 'xmlns' && isset($parts[1]) && strncmp('http://typo3.org/ns/', $value, 20) === 0) {
48
                $namespace = $resolver->resolvePhpNamespaceFromFluidNamespace($value);
49
                $resolver->addNamespace($parts[1], $namespace);
50
                $this->namespaces[$parts[1]][] = $namespace;
51
                unset($arguments[$name]);
52
            }
53
        }
54
        return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (TYPO3Fluid\Fluid\ViewHelpers\HtmlViewHelper) is incompatible with the return type declared by the interface TYPO3Fluid\Fluid\Compone...ponentInterface::onOpen of type self.

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:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
55
    }
56
57
    public function onClose(RenderingContextInterface $renderingContext): ComponentInterface
58
    {
59
        return $this;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $this; (TYPO3Fluid\Fluid\ViewHelpers\HtmlViewHelper) is incompatible with the return type declared by the interface TYPO3Fluid\Fluid\Compone...onentInterface::onClose of type self.

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:

class Author {
    private $name;

    public function __construct($name) {
        $this->name = $name;
    }

    public function getName() {
        return $this->name;
    }
}

abstract class Post {
    public function getAuthor() {
        return 'Johannes';
    }
}

class BlogPost extends Post {
    public function getAuthor() {
        return new Author('Johannes');
    }
}

class ForumPost extends Post { /* ... */ }

function my_function(Post $post) {
    echo strtoupper($post->getAuthor());
}

Our function my_function expects a Post object, and outputs the author of the post. The base class Post returns a simple string and outputting a simple string will work just fine. However, the child class BlogPost which is a sub-type of Post instead decided to return an object, and is therefore violating the SOLID principles. If a BlogPost were passed to my_function, PHP would not complain, but ultimately fail when executing the strtoupper call in its body.

Loading history...
60
    }
61
62
    /**
63
     * @param RenderingContextInterface $renderingContext
64
     * @return mixed
65
     */
66
    public function evaluate(RenderingContextInterface $renderingContext)
67
    {
68
        $content = $this->evaluateChildren($renderingContext);
69
        if (!$this->shouldRenderTag) {
70
            return $content;
71
        }
72
73
        $tagBuilder = new TagBuilder('html');
74
        $tagBuilder->ignoreEmptyAttributes(true);
75
        $tagBuilder->addAttributes($this->arguments->setRenderingContext($renderingContext)->getArrayCopy());
76
        $tagBuilder->setContent($content);
77
        return $tagBuilder->render();
78
    }
79
80
    public function allowUndeclaredArgument(string $argumentName): bool
81
    {
82
        return true;
83
    }
84
}
85