mediawiki-extensions-Discus.../includes/NodeFilter.php

62 lines
1.5 KiB
PHP
Raw Normal View History

<?php
namespace MediaWiki\Extension\DiscussionTools;
use DOMException;
Don't refer directly to PHP `dom` extension classes; avoid nonstandard behavior These changes ensure that DiscussionTools is independent of DOM library choice, and will not break if/when Parsoid switches to an alternate (more standards-compliant) DOM library. We run `phan` against the Dodo standards-compliant DOM library, so this ends up flagging uses of non-standard PHP extensions to the DOM. These will be suppressed for now with a "Nonstandard DOM" comment that can be grepped for, since they will eventually will need to be rewritten or worked around. Most frequent issues: * Node::nodeValue and Node::textContent and Element::getAttribute() can return null in a spec-compliant implementation. Add `?? ''` to make spec-compliant results consistent w/ what PHP returns. * DOMXPath doesn't accept anything except DOMDocument. These uses should be replaced with DOMCompat::querySelectorAll() or similar (which end up using DOMXPath under the covers for DOMDocument any way, but are implemented more efficiently in a spec-compliant implementation). * A couple of times we have code like: `while ($node->firstChild!==null) { $node = $node->firstChild; }` and phan's analysis isn't strong enough to determine that $node is still non-null after the while. This same issue should appear with DOMDocument but phan doesn't complain for some reason. One apparently legit issue: * Node::insertBefore() is once called in a funny way which leans on the fact that the second option is optional in PHP. This seems to be a workaround for an ancient PHP bug, and can probably be safely removed. Bug: T287611 Bug: T217867 Change-Id: I3c4f41c3819770f85d68157c9f690d650b7266a3
2021-07-29 02:16:15 +00:00
use Wikimedia\Parsoid\DOM\Node;
/**
* Partial implementation of W3 DOM4 NodeFilter interface.
*
* See also:
* - https://dom.spec.whatwg.org/#interface-nodefilter
*
* Adapted from https://github.com/Krinkle/dom-TreeWalker-polyfill/blob/master/src/TreeWalker-polyfill.js
*/
class NodeFilter {
// Constants for acceptNode()
public const FILTER_ACCEPT = 1;
public const FILTER_REJECT = 2;
public const FILTER_SKIP = 3;
// Constants for whatToShow
public const SHOW_ALL = 0xFFFFFFFF;
public const SHOW_ELEMENT = 0x1;
public const SHOW_ATTRIBUTE = 0x2;
public const SHOW_TEXT = 0x4;
public const SHOW_CDATA_SECTION = 0x8;
public const SHOW_ENTITY_REFERENCE = 0x10;
public const SHOW_ENTITY = 0x20;
public const SHOW_PROCESSING_INSTRUCTION = 0x40;
public const SHOW_COMMENT = 0x80;
public const SHOW_DOCUMENT = 0x100;
public const SHOW_DOCUMENT_TYPE = 0x200;
public const SHOW_DOCUMENT_FRAGMENT = 0x400;
public const SHOW_NOTATION = 0x800;
/** @var callable */
public $filter;
private bool $active = false;
/**
* See https://dom.spec.whatwg.org/#dom-nodefilter-acceptnode
*
Don't refer directly to PHP `dom` extension classes; avoid nonstandard behavior These changes ensure that DiscussionTools is independent of DOM library choice, and will not break if/when Parsoid switches to an alternate (more standards-compliant) DOM library. We run `phan` against the Dodo standards-compliant DOM library, so this ends up flagging uses of non-standard PHP extensions to the DOM. These will be suppressed for now with a "Nonstandard DOM" comment that can be grepped for, since they will eventually will need to be rewritten or worked around. Most frequent issues: * Node::nodeValue and Node::textContent and Element::getAttribute() can return null in a spec-compliant implementation. Add `?? ''` to make spec-compliant results consistent w/ what PHP returns. * DOMXPath doesn't accept anything except DOMDocument. These uses should be replaced with DOMCompat::querySelectorAll() or similar (which end up using DOMXPath under the covers for DOMDocument any way, but are implemented more efficiently in a spec-compliant implementation). * A couple of times we have code like: `while ($node->firstChild!==null) { $node = $node->firstChild; }` and phan's analysis isn't strong enough to determine that $node is still non-null after the while. This same issue should appear with DOMDocument but phan doesn't complain for some reason. One apparently legit issue: * Node::insertBefore() is once called in a funny way which leans on the fact that the second option is optional in PHP. This seems to be a workaround for an ancient PHP bug, and can probably be safely removed. Bug: T287611 Bug: T217867 Change-Id: I3c4f41c3819770f85d68157c9f690d650b7266a3
2021-07-29 02:16:15 +00:00
* @param Node $node
* @return int Constant NodeFilter::FILTER_ACCEPT,
* NodeFilter::FILTER_REJECT or NodeFilter::FILTER_SKIP.
*/
public function acceptNode( $node ) {
if ( $this->active ) {
throw new DOMException( 'INVALID_STATE_ERR' );
}
$this->active = true;
$result = call_user_func( $this->filter, $node );
$this->active = false;
return $result;
}
}