Completed
Push — master ( 2a517c...a42c86 )
by Lars
04:47
created

SimpleHtmlDomNode::text()   A

Complexity

Conditions 2
Paths 2

Size

Total Lines 9
Code Lines 5

Duplication

Lines 0
Ratio 0 %

Code Coverage

Tests 6
CRAP Score 2

Importance

Changes 0
Metric Value
c 0
b 0
f 0
dl 0
loc 9
ccs 6
cts 6
cp 1
rs 9.6666
cc 2
eloc 5
nc 2
nop 0
crap 2
1
<?php
2
3
namespace voku\helper;
4
5
/**
6
 * Class SimpleHtmlDomNode
7
 *
8
 * @package voku\helper
9
 *
10
 * @property-read string outertext <p>Get dom node's outer html.</p>
11
 * @property-read string plaintext <p>Get dom node's plain text.</p>
12
 */
13
class SimpleHtmlDomNode extends \ArrayObject implements SimpleHtmlDomNodeInterface
14
{
15
  /** @noinspection MagicMethodsValidityInspection */
16
  /**
17
   * @param string $name
18
   *
19
   * @return array|null
20
   */
21 3
  public function __get($name)
22
  {
23 3
    $name = strtolower($name);
24
25 3
    if ($this->count() > 0) {
26 3
      $return = array();
27
28 3
      foreach ($this as $node) {
29 3
        if ($node instanceof SimpleHtmlDom) {
30 3
          $return[] = $node->{$name};
31 3
        }
32 3
      }
33
34 3
      return $return;
35
    }
36
37
    return null;
38
  }
39
40
  /**
41
   * alias for "$this->innerHtml()" (added for compatibly-reasons with v1.x)
42
   */
43
  public function outertext()
44
  {
45
    $this->innerHtml();
0 ignored issues
show
Unused Code introduced by
The call to the method voku\helper\SimpleHtmlDomNode::innerHtml() seems un-needed as the method has no side-effects.

PHP Analyzer performs a side-effects analysis of your code. A side-effect is basically anything that might be visible after the scope of the method is left.

Let’s take a look at an example:

class User
{
    private $email;

    public function getEmail()
    {
        return $this->email;
    }

    public function setEmail($email)
    {
        $this->email = $email;
    }
}

If we look at the getEmail() method, we can see that it has no side-effect. Whether you call this method or not, no future calls to other methods are affected by this. As such code as the following is useless:

$user = new User();
$user->getEmail(); // This line could safely be removed as it has no effect.

On the hand, if we look at the setEmail(), this method _has_ side-effects. In the following case, we could not remove the method call:

$user = new User();
$user->setEmail('email@domain'); // This line has a side-effect (it changes an
                                 // instance variable).
Loading history...
46
  }
47
48
  /**
49
   * alias for "$this->innerHtml()" (added for compatibly-reasons with v1.x)
50
   */
51
  public function innertext()
52
  {
53
    $this->innerHtml();
0 ignored issues
show
Unused Code introduced by
The call to the method voku\helper\SimpleHtmlDomNode::innerHtml() seems un-needed as the method has no side-effects.

PHP Analyzer performs a side-effects analysis of your code. A side-effect is basically anything that might be visible after the scope of the method is left.

Let’s take a look at an example:

class User
{
    private $email;

    public function getEmail()
    {
        return $this->email;
    }

    public function setEmail($email)
    {
        $this->email = $email;
    }
}

If we look at the getEmail() method, we can see that it has no side-effect. Whether you call this method or not, no future calls to other methods are affected by this. As such code as the following is useless:

$user = new User();
$user->getEmail(); // This line could safely be removed as it has no effect.

On the hand, if we look at the setEmail(), this method _has_ side-effects. In the following case, we could not remove the method call:

$user = new User();
$user->setEmail('email@domain'); // This line has a side-effect (it changes an
                                 // instance variable).
Loading history...
54
  }
55
56
  /**
57
   * @param string $selector
58
   * @param int    $idx
59
   *
60
   * @return SimpleHtmlDomNode[]|SimpleHtmlDomNode|null
61
   */
62
  public function __invoke($selector, $idx = null)
63
  {
64
    return $this->find($selector, $idx);
65
  }
66
67
  /**
68
   * @return string
69
   */
70 1
  public function __toString()
71
  {
72 1
    $html = '';
73 1
    foreach ($this as $node) {
74 1
      $html .= $node->outertext;
75 1
    }
76
77 1
    return $html;
78
  }
79
80
  /**
81
   * Find list of nodes with a CSS selector.
82
   *
83
   * @param string $selector
84
   * @param int    $idx
85
   *
86
   * @return SimpleHtmlDomNode[]|SimpleHtmlDomNode|null
87
   */
88 11
  public function find($selector, $idx = null)
89
  {
90 11
    $elements = new self();
91 11
    foreach ($this as $node) {
92 11
      foreach ($node->find($selector) as $res) {
93 10
        $elements->append($res);
94 11
      }
95 11
    }
96
97
    // return all elements
98 11
    if (null === $idx) {
99 11
      return $elements;
100
    }
101
102
    // handle negative values
103
    if ($idx < 0) {
104
      $idx = count($elements) + $idx;
105
    }
106
107
    // return one element
108
    if (isset($elements[$idx])) {
109
      return $elements[$idx];
110
    }
111
112
    return null;
113
  }
114
115
  /**
116
   * Get html of elements.
117
   *
118
   * @return array
119
   */
120 1
  public function innerHtml()
121
  {
122 1
    $html = array();
123 1
    foreach ($this as $node) {
124 1
      $html[] = $node->outertext;
125 1
    }
126
127 1
    return $html;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $html; (array) is incompatible with the return type declared by the interface voku\helper\SimpleHtmlDomNodeInterface::innerHtml of type string.

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...
128
  }
129
130
  /**
131
   * Get plain text.
132
   *
133
   * @return array
134
   */
135 2
  public function text()
136
  {
137 2
    $text = array();
138 2
    foreach ($this as $node) {
139 2
      $text[] = $node->plaintext;
140 2
    }
141
142 2
    return $text;
0 ignored issues
show
Bug Best Practice introduced by
The return type of return $text; (array) is incompatible with the return type declared by the interface voku\helper\SimpleHtmlDomNodeInterface::text of type string.

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...
143
  }
144
}
145