Provide a mechanism in VRS/RESTbase for switching between WT and DOM
Closed, ResolvedPublic8 Story Points

Description

We in VisualEditor want to:

  1. start from the DOM, A of a current revision, W;
  2. make some changes against it in DOM format, 'A;
  3. get the wikitext of the document given those changes, 'W;
  4. rather than save it, make some changes to the wikitext ''W;
  5. get the DOM of those changes, ''A; and
  6. then make some further changes DOM, saving as B (as Y in wikitext)

… without introducing lots of wikitext normalisations.

Steps 1-3 are current functionality; however, AIUI steps 4 & 5 would be slow (as it would involve round-tripping the entire document through the Parsoid pipeline) and normalise the wikitext as selser wouldn't have ''A as a reference version of the wikitext available to Parsoid).

Help?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 3 2015, 12:09 AM
Krenair edited the task description. (Show Details)Jul 3 2015, 12:12 AM
Krenair set Security to None.
Arlolra moved this task from Backlog to Non-Parsoid Tasks on the Parsoid board.Jul 7 2015, 2:42 AM
Jdforrester-WMF triaged this task as "High" priority.Oct 2 2015, 7:54 PM
Jdforrester-WMF added a project: VisualEditor.
Jdforrester-WMF changed the title from "Provide a mechanism in RESTbase for switching between WT and DOM" to "Provide a mechanism in VRS/RESTbase for switching between WT and DOM".Oct 7 2015, 8:51 PM
Jdforrester-WMF edited a custom field.

@Krenair, could you look at this?

I understood this to be new Parsoid functionality?

I understood this to be new Parsoid functionality?

The 'new' stuff is to give the reference wikitext to Parsoid from RESTbase's cache (new in T114548, now in production), rather than from RESTbase's store of saved revisions.

GWicke added a comment.EditedOct 7 2015, 10:08 PM

That, along with the ability to stash things (html, data-parsoid, wikitext of a wt2html conversion) in RESTBase.

To clarify, here's how it works. When transforming from wikitext to HTML using the /apge/transform/wikitext/to/html/{title}/{revision} endpoint, you need to supply and extra stash flag in the body:

body:
  wikitext: 'blah blah',
  stash: true

You will get back the HTML, but the response will contain a special ETag header. Next, after the user modifies the HTML and you need to transform that back to wikitext (either for saving or further editing, no difference) using the /page/transform/html/to/wikitext/{title}/{revision} endpoint, you need to include the previously-received ETag header as the If-Match` header:

headers:
  if-match: {etag_from_wt2html}
body:
  html: '<p>blah blah</p>'

That will prompt RESTBase to send the stashed, modified version of wikitext and data-parsoid to Parsoid rather than the original, vanilla ones. Note also that this functionality is available only in RESTBase, not Parsoid.

@Krenair, @Jdforrester-WMF there is currently a limitation in the stashing mechanism that requires you to supply both the title and revision. This implies it will not work for page creation. Is this an edge case we care about?

I think we only need this to deal with already-modified wikitext, but that can be worked around anyway.

GWicke added a comment.Oct 9 2015, 3:35 PM

Note that passing in a fake revision '0' should work as well. Setting the page name correctly will make sure that page-dependent magic words, relative links etc work correctly in the wt2html conversion.

I think we only need this to deal with already-modified wikitext, but that can be worked around anyway.

Great! If it pops up as a use case, we can revisit it.

Note that passing in a fake revision '0' should work as well.

It wouldn't pass the getBuckerURI() check, causing key_rev_value to return a 400 on a PUT (which happens during stashing), but that's a minor detail.

GWicke added a comment.Oct 9 2015, 3:41 PM

It wouldn't pass the getBuckerURI() check, causing key_rev_value to return a 400 on a PUT (which happens during stashing), but that's a minor detail.

Hmm, yeah. Use revision '1' instead ;)

I'm wondering about the scope of this ticket now... We seem to have most of the RESTBase parts in place (except T115165: Add Access-Control-Expose-Headers header in response to allow access to ETag) and AFAIK, VRS does not need to be changed.

Krenair closed this task as "Resolved".Oct 20 2015, 12:23 AM
Krenair reassigned this task from Krenair to mobrovac.