wikimedia/mediawiki-extensions-VisualEditor
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/VisualEditor synced 2024-11-15 02:23:58 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Visual.../includes/ParsoidClient.php

63 lines
2.1 KiB
PHP
Raw Normal View History

Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
<?php
namespace MediaWiki\Extension\VisualEditor;
use MediaWiki\Page\PageIdentity;
use MediaWiki\Revision\RevisionRecord;
Change almost all code to use Bcp47Code instead of Language This patch makes the following assumptions: 1. There is no class outside of this codebase that implements the ParsoidClient interface. According to CodeSearch this appears to be correct. 2. It is fine to use the Bcp47Code instead of the internal MediaWiki language code in the "Accept-Language" HTTP header. As far as I understand this might even qualify as a bugfix. Depends-On: If059674597e261039df7f4613a89cb08120c3262 Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
2023-07-07 08:11:15 +00:00
use Wikimedia\Bcp47Code\Bcp47Code;
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
interface ParsoidClient {
/**
* Request page HTML
*
* @param RevisionRecord $revision Page revision
Change almost all code to use Bcp47Code instead of Language This patch makes the following assumptions: 1. There is no class outside of this codebase that implements the ParsoidClient interface. According to CodeSearch this appears to be correct. 2. It is fine to use the Bcp47Code instead of the internal MediaWiki language code in the "Accept-Language" HTTP header. As far as I understand this might even qualify as a bugfix. Depends-On: If059674597e261039df7f4613a89cb08120c3262 Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
2023-07-07 08:11:15 +00:00
* @param Bcp47Code|null $targetLanguage Desired output language
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
*
ApiParsoidTrait/DirectParsoidClient: Simplify error handling After catching the REST exception, just throw an API exception. Remove the step inbetween where we built a response array. Bonus: * Remove tests that only tested this array building. * Remove the unused 'code' from successful responses, and update documentation of return value shapes. * Remove impossible check for `$ex instanceof LocalizedException`. After moving the code into one place, it's obvious that it can't happen, since LocalizedException doesn't inherit from HttpException. Bug: T341613 Change-Id: I31370efeed9d5283b53eafca102b2f1efc811d27
2023-08-14 15:14:12 +00:00
* @return array An array mimicking a RESTbase server's response, with keys: 'headers' and 'body'
* @phan-return array{body:string,headers:array<string,string>}
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
*/
Change almost all code to use Bcp47Code instead of Language This patch makes the following assumptions: 1. There is no class outside of this codebase that implements the ParsoidClient interface. According to CodeSearch this appears to be correct. 2. It is fine to use the Bcp47Code instead of the internal MediaWiki language code in the "Accept-Language" HTTP header. As far as I understand this might even qualify as a bugfix. Depends-On: If059674597e261039df7f4613a89cb08120c3262 Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
2023-07-07 08:11:15 +00:00
public function getPageHtml( RevisionRecord $revision, ?Bcp47Code $targetLanguage ): array;
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
/**
* Transform HTML to wikitext via Parsoid
*
* @param PageIdentity $page The page the content belongs to
Change almost all code to use Bcp47Code instead of Language This patch makes the following assumptions: 1. There is no class outside of this codebase that implements the ParsoidClient interface. According to CodeSearch this appears to be correct. 2. It is fine to use the Bcp47Code instead of the internal MediaWiki language code in the "Accept-Language" HTTP header. As far as I understand this might even qualify as a bugfix. Depends-On: If059674597e261039df7f4613a89cb08120c3262 Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
2023-07-07 08:11:15 +00:00
* @param Bcp47Code $targetLanguage The desired output language
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
* @param string $html The HTML of the page to be transformed
* @param ?int $oldid What oldid revision, if any, to base the request from (default: `null`)
* @param ?string $etag The ETag to set in the HTTP request header
*
ApiParsoidTrait/DirectParsoidClient: Simplify error handling After catching the REST exception, just throw an API exception. Remove the step inbetween where we built a response array. Bonus: * Remove tests that only tested this array building. * Remove the unused 'code' from successful responses, and update documentation of return value shapes. * Remove impossible check for `$ex instanceof LocalizedException`. After moving the code into one place, it's obvious that it can't happen, since LocalizedException doesn't inherit from HttpException. Bug: T341613 Change-Id: I31370efeed9d5283b53eafca102b2f1efc811d27
2023-08-14 15:14:12 +00:00
* @return array An array mimicking a RESTbase server's response, with keys: 'headers' and 'body'
* @phan-return array{body:string,headers:array<string,string>}
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
*/
public function transformHTML(
PageIdentity $page,
Change almost all code to use Bcp47Code instead of Language This patch makes the following assumptions: 1. There is no class outside of this codebase that implements the ParsoidClient interface. According to CodeSearch this appears to be correct. 2. It is fine to use the Bcp47Code instead of the internal MediaWiki language code in the "Accept-Language" HTTP header. As far as I understand this might even qualify as a bugfix. Depends-On: If059674597e261039df7f4613a89cb08120c3262 Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
2023-07-07 08:11:15 +00:00
Bcp47Code $targetLanguage,
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
string $html,
?int $oldid,
?string $etag
): array;
/**
* Transform wikitext to HTML via Parsoid.
*
* @param PageIdentity $page The page the content belongs to
Change almost all code to use Bcp47Code instead of Language This patch makes the following assumptions: 1. There is no class outside of this codebase that implements the ParsoidClient interface. According to CodeSearch this appears to be correct. 2. It is fine to use the Bcp47Code instead of the internal MediaWiki language code in the "Accept-Language" HTTP header. As far as I understand this might even qualify as a bugfix. Depends-On: If059674597e261039df7f4613a89cb08120c3262 Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
2023-07-07 08:11:15 +00:00
* @param Bcp47Code $targetLanguage The desired output language
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
* @param string $wikitext The wikitext fragment to parse
* @param bool $bodyOnly Whether to provide only the contents of the `<body>` tag
* @param ?int $oldid What oldid revision, if any, to base the request from (default: `null`)
* @param bool $stash Whether to stash the result in the server-side cache (default: `false`)
*
ApiParsoidTrait/DirectParsoidClient: Simplify error handling After catching the REST exception, just throw an API exception. Remove the step inbetween where we built a response array. Bonus: * Remove tests that only tested this array building. * Remove the unused 'code' from successful responses, and update documentation of return value shapes. * Remove impossible check for `$ex instanceof LocalizedException`. After moving the code into one place, it's obvious that it can't happen, since LocalizedException doesn't inherit from HttpException. Bug: T341613 Change-Id: I31370efeed9d5283b53eafca102b2f1efc811d27
2023-08-14 15:14:12 +00:00
* @return array An array mimicking a RESTbase server's response, with keys: 'headers' and 'body'
* @phan-return array{body:string,headers:array<string,string>}
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
*/
public function transformWikitext(
PageIdentity $page,
Change almost all code to use Bcp47Code instead of Language This patch makes the following assumptions: 1. There is no class outside of this codebase that implements the ParsoidClient interface. According to CodeSearch this appears to be correct. 2. It is fine to use the Bcp47Code instead of the internal MediaWiki language code in the "Accept-Language" HTTP header. As far as I understand this might even qualify as a bugfix. Depends-On: If059674597e261039df7f4613a89cb08120c3262 Change-Id: Icd160da2d5555891b9a91a0cb966bd36a55f6fdd
2023-07-07 08:11:15 +00:00
Bcp47Code $targetLanguage,
Extract RESTbase client code into VRSParsoidClient. This makes the "direct" client and the VRS based client implement the same interface, so the caller doesn't have to know which one it is using. It looks like ParsoidHelper will not be needed if we use this approach. Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
2022-09-04 09:00:14 +00:00
string $wikitext,
bool $bodyOnly,
?int $oldid,
bool $stash
): array;
}
Reference in a new issue Copy permalink