Html Export Facilities, part 1

[dbolack-ab]

Description

This is the first part of a proposed feature extension that allows for downloading the Brew Render as HTML.

Downloads will be available as

• HTML - The same output as the brewRender window, with any relative paths altered to be fully expanded
• Zipped - An archive of the Brew Render with all external files in a tree structure and file references altered to match

This also adds the /embed endpoint, which is a modified version of share without the tool and navbar. This is for external embedding or services like DocRaptor to ingest.

Currently only downloads the HTML from the brewRender window with no URL massaging ( all relative path references are still relative ) and a default filename.

Related Issues or Discussions

• [FEATURE]: Downloadable CSS + HTML bundle #661

To Do

• HTML
  • Best Effort rewrite local, relative paths
• Zip
  • Create Zip
  • Rewrite Paths for CSS to local-to-zip path
  • Store CSS in Zip
  • Rewrite image paths
  • Store Images in zip

[calculuschild]

The general idea here is OK to me. Personally, I would say the .zip is the most useful, followed by the "slim".

My main feedback is that this added helper simulateRenderPage() is nearly identical to the existing page render function, so there is a lot of duplication and now two places we need to maintain if the rendering sequence changes.

My preferred approach would actually be to just grab the already-generated HTML straight from the DOM, similar to what we do for generating the PDF. Is that possible to reduce the duplication?

[dbolack-ab]

The general idea here is OK to me. Personally, I would say the .zip is the most useful, followed by the "slim".

Based on the unclear requests and general non-answers to follow-up questions, these three modes all seem to be equally requested. "Slim" is the most obvious as it should be handy for embedding or passing to an external process, like DocRaptor, similar to the way the old print endpoint did.

I can see an argument for dropping inline if we insist that the zipfile adds all remote files to the archive ( probably everyone's assumption? )

My preferred approach would actually be to just grab the already-generated HTML straight from the DOM, similar to what we do for generating the PDF. Is that possible to reduce the duplication?

I don't know that that is a bad idea but in order to work in all the scenarios I am targeting it would mean taking the HTML and posting it to the endpoint. That could be a bit.. large.

At the moment, I don't recall what all I trimmed out/adapted - maybe we could consolidate the duplication even if it means a slightly more challenging to read function/functions.