[go: up one dir, main page]

Page MenuHomePhabricator

ApiVisualEditor: Convert ApiParsoidTrait into a helper object.
Closed, ResolvedPublic

Description

ApiParsoidTrait should be replaced by a helper object interface with two implementations:

  1. the current implementation based on HTTP calls to RESTbase and faux requests to the action API
  2. a new implementation based on directly accessing service objects (needs T310377).
NOTE: The refactoring work for the existing code can be started right away, only the second implementation is blocked on having the parsoid transforms available internally.

Related Objects

StatusSubtypeAssignedTask
StalledNone
In ProgressNone
OpenNone
OpenNone
ResolvedJgiannelos
Resolveddaniel
ResolvedClement_Goubert
DeclinedNone
Resolvedhnowlan
In ProgressNone
Resolveddaniel
ResolvedNone
Resolvedmatmarex
OpenMSantos
ResolvedMSantos
ResolvedMSantos
ResolvedROdonnell-WMF
ResolvedBUG REPORTMSantos
ResolvedBUG REPORTdaniel
ResolvedBUG REPORTdaniel
OpenBUG REPORTNone
InvalidNone
Resolveddaniel
ResolvedBPirkle
In Progressdaniel
DuplicateNone
Stalleddaniel
Resolveddaniel
Resolveddaniel
Resolveddaniel
In Progressdaniel
Resolveddaniel
Opendaniel
OpenNone
Resolveddaniel
Resolveddaniel
Resolveddaniel
DeclinedNone
OpenNone
OpenJgiannelos
ResolvedBPirkle
ResolvedJgiannelos
OpenNone
Openakosiaris

Event Timeline

In the longer term, this trait/helper should probably be replaced by direct calls to classes/methods provided by MediaWiki for fetching and transforming page contents. If it's possible to replace any parts now, please feel free to do that :D

(Also, when refactoring, note that the trait is also used by the DiscussionTools extension.)

It looks like getLatestRevision() and getValidRevision() could both be easily deleted, and replaced with some smarter use of RevisionLookup::getRevisionByTitle().

In the longer term, this trait/helper should probably be replaced by direct calls to classes/methods provided by MediaWiki for fetching and transforming page contents.

Yes, that's the idea. However, we need to make the transition carefully, so there should be a feature flag that controls the way that ApiVisualEditor calls Parsoid. I suppose we'll forst only swicth it for mediawiki.org.

Also, when refactoring, note that the trait is also used by the DiscussionTools extension.

Oh, that is good to know! Thanks for the warning!

It looks like getLatestRevision() and getValidRevision() could both be easily deleted, and replaced with some smarter use of RevisionLookup::getRevisionByTitle().

Probably.

This has suddenly become high priority for me, as I need to be able to access Parsoid HTML in non-action-API contexts for T296801, and the ParsoidOutputAccess helper which I was going to use is verboten according to comments on https://gerrit.wikimedia.org/r/c/mediawiki/extensions/DiscussionTools/+/815289. I will start working on patches, I hope some folks here will have time to review.

Change 821803 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/VisualEditor@master] Create yet another parsoid helper

https://gerrit.wikimedia.org/r/821803

Change 821803 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Create Parsoid helper for use outside of action API

https://gerrit.wikimedia.org/r/821803

@daniel I'm not sure what was the intended scope of this task, but from my perspective it is done now. Let us know what you had in mind and whether we can close it (when you're back).

@daniel I'm not sure what was the intended scope of this task, but from my perspective it is done now. Let us know what you had in mind and whether we can close it (when you're back).

If the helper class you interoduced is now the only place where calls are made to RESTbase, then this task can be closed as done. Thank you!