This ensures that Parsoid and core can communicate using a common
interface. By reusing Parsoid's trait it also eliminates code duplication
between LinkTarget, Title, and TitleValue.
Even though Parsoid's LinkTarget interface is identical to core's, I've
elected not to leave an empty LinkTarget interface in core but instead to
(re)define the interface methods in order to make core slightly more
self-contained and avoid the need for core hackers to consult the
Parsoid codebase for the definitions of LinkTarget methods.
A small number of types in core were broadened to accept a Parsoid
LinkTarget instead of just a core LinkTarget, but these changes should
be minimal: only core which directly communicates with Parsoid should
need to know about Parsoid's superinterface here.
Bug: T296023
Depends-On: Id6ad5ac3b8d1c21c129fa94c10879a1632ed4b47
Depends-On: I59794e98c9881aff3ea6a258bf7d1660a203eb84
Depends-On: Ifc14c0ffc43c7939a6e6b55e00fe2f453fa143a1
Change-Id: I9adc349b230834827b002f412dcc697b44773abe
The various classes and interfaces for representing titles, links, and
pages can be a bit confusing. Link to a wiki page that provides an
overview:
https://www.mediawiki.org/wiki/Manual:Modeling_pages
Change-Id: I04fcf53bd15ca50a2bbb8693482a99ab651a4b30
* The Title::inNamespace() method discouraged use of getNamespace()
for comparison.
This was added 10 years ago in r103893 (commit 3414e91bae),
however no such "change" has been made, and the new LinkTarget
stable interface and TitleValue class contains the same getNamespace()
method, and no warning against its use.
My main reason for removing this comment is so that avoid fear
against using `in_array()` with TitleValue->getNamespace() which
this comment seems to discourage. While Title has plural
inNamespaces(), TitleValue does not. This seems fine, as one can
simply use in_array for more complex use cases where a range or
list is compared against.
* Fix Doxygen warnings about invalid or unsupported XML tags
such as `<a>`, `<siteinfo>` etc. Rephase or use backtics,.
* Fix useless IDE tooltips and Doxygen output by removing empty stubs
from method overrides that add no new information, yet obscured
the otherwise inherited parent destination which does have useful
information.
* Clarify that `renderForComment` must not be mixed with other ones.
This seems to be how it is intended. Upon realizing that, I think
this is unreasonable and should perhaps be removed. For now, I've
documented the hack that it seems to exist for.
* Consistently use imperative mood when phrasing method docs, and
consistently use a brief first line description, and
consistently separate it from other paragraphs and annotations
with one line break.
Change-Id: I7e1819a5d7124c635de84bc64d2371a122195928
These type-hints are definitely correct, but it's still
a relatively risky patch cause of how messy Title is.
I did some manual review of Title, all tests are passing,
but even still if this is approved, I'll add it to phab
as a risky deployment.
Change-Id: I1ed98ddae30066956e7adbde6780d6bab54dec04
Redundant given this is the project-wide license already,
especially in file headers that already include the GPL license
header.
This and other minor fixups based on feedback from Ie0cea0ef5027c7e5.
* Add @file where missing.
* Move @ingroup and @deprecated from file to class doc where needed.
Change-Id: I7067abb7abee1f0c238cb2536e16192e946d8daa
This adds support to the LinkTarget interface and TitleValue
implementation for having an interwiki component, matching the function
names used in Title.
MediaWikiTitleCodec was updated accordingly.
The motivation behind this change is to be able to fully use LinkTarget
in the Linker rewrite instead of depending upon Title.
Change-Id: I6666b64f0e336aadc7261e7ca87ac2e498c61856
