Toward a more modern frontend and backend for Pages.

[jmchilton]

For the backend: Refactor a ton of the web controller backend code into managers so that the pages API is fully functional and supports embedded objects and such. Add tests for database encoding, better error handling throughout with various tests for that. Cleanup some unused code around annotation handling.

For the frontend: Add a selenium test for simple page creation, viewing, and adding embedded objects. Eliminate a bunch of the mako code for Galaxy page editor landing - simply place an encoded page ID in the DOM and let JavaScript and the API take care of things. Refactor nearly all of galaxy.pages.js into a PageEditor VueJS component. Cleanup unused mako and JS. Split the editor component into a wrapper and a content format (HTML) specific editor - to allow adding a second editor for Markdown downstream. The Vue isn't great reactive Vue because most the code is the same thing - but it is an atomic set of refactorings in the correct direction I believe.

Why? Enables inserting a new page format based on Markdown downstream - see how it is used in context at jmchilton@33a4933. This commit reuses VueJS Markdown editor and viewer components developed for workflow invocation reports for page editing and rendering.

[dannon]

@jmchilton I haven't done a thorough review yet, but this looks like a nice step forward refactoring the pages entrypoint and the tests will definitely be helpful. Out of curiosity, did you happen to look into other alternatives to wym?

[jmchilton]

@dannon I would like HTML-based pages to be a development dead-end - markdown is the future IMO (jmchilton@33a4933 not included in the PR). Even if we decide as a project to continue to invest in a WYSIWG HTML editor, it isn't a personal interest.

For Markdown, I think it will be easy enough to roll our own editor in order to support Galaxy-specific extensions as long as we have good components for rendering the Markdown in real-time, caching requests, and such. I have done some looking around for editors but I haven't been impressed with the customizability or really value-add of anything I've found.

[dannon]

@jmchilton Totally agreed on markdown being the future for pages; I'm mainly concerned with the migration path here and I was wondering if there was a slightly more modern editor that'd drop in (in a couple hours time or less!) to buy some time. I would like to completely drop the HTML editor, but I guess at that point we'd need a conversion mechanism. Which might not be that awful, given that the html is fairly simple and limited as-is?

[jmchilton]

I'm usually more conservative on these things but to me it seems we more have conversations about whether to keep pages around at all... given this I don't think there is enough valuable content locked up in pages currently to warrant worrying about a conversion process or replacing the existing HTML functionality at this time. My preference is to just maintain the current pages and focus on writing new pages in Markdown.

I'm not opening a PR to axe them or anything... I just don't want to invest in them in anyway at this time (personally).

[dannon]

@jmchilton I guess what I was beating around the bush about was that I want to axe wymeditor completely. Just looking for the right way to do that.

[jmchilton]

@dannon My preference... give Markdown a release cycle, axe the HTML editor completely - those pages will be read-only - and then see if anyone complains 😄. Not enough people will to bring it back and you will have your wish. Not enough people use pages to fight for them I think.

[dannon]

@jmchilton Thanks for the work and thinking on this, that sounds good to me. I was thinking similar, but with an 'attempt to convert my page to markdown' button, but maybe that's not worth the effort if they're still accessible and read only. WYM has popped up as a thorn in my side every time I try to work on code splitting, entrypoints, jquery upgrades, etc. for a while now, so this is exciting.

[jmchilton]

Work continued in #8512.