Differential D14289
Introduce PHUIRemarkupView, a sane way to work with Remarkup Authored by epriestley on Oct 15 2015, 5:09 PM. Tags None Referenced Files
Subscribers None
Details
Fixes T9273. Remarkup has reasonably good fundamentals but the API is a giant pain to work with. Provide a PHUIRemarkupView to make it easier. This object is way simpler to use by default. It's not currently as powerful, but we can expand the power level later by adding more setters. Eventually I'd expect to replace PhabricatorRemarkupInterface and PhabricatorMarkupOneOff with this, but no rush on those. I converted a few callsites as a sanity check that it works OK.
Diff Detail
Event TimelineComment Actions Yeahh, I thought this was going to be like an hour of work to get a v1 but I think we're totally fine like this for now. The downside to this approach is that we aren't sharing the engine between views, but that's fine (we weren't with MarkupOneOff anyway, so we can replace all of those at no cost). Once we start replacing PhabricatorMarkupInterface this class will have to get a bit smarter to avoid creating a performance cost, and I think it will eventually be ~10-20x more complex than this (with a mixture of options, engine management, and render pipelining) but we can fix like 90% of the "this is horrible to work with because you have to type 50 lines of garbage" stuff really easily right now and worry about the perf stuff later. In the longer run, the views can pool themselves on the $viewer (like Handles do) and coordinate access to a smaller number of engines that way, and we can pass engines in to support pipelining too. Basically, this is way better for working with Remarkup, and has plenty of flexibility for improving the backend later. |
