2012-12-07 16:19:57 -08:00
|
|
|
<?php
|
|
|
|
|
2015-06-15 18:02:26 +10:00
|
|
|
abstract class DifferentialChangesetRenderer extends Phobject {
|
2012-12-07 16:19:57 -08:00
|
|
|
|
|
|
|
private $user;
|
|
|
|
private $changeset;
|
|
|
|
private $renderingReference;
|
|
|
|
private $renderPropertyChangeHeader;
|
2013-09-12 16:00:00 -07:00
|
|
|
private $isTopLevel;
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 12:07:46 -07:00
|
|
|
private $isUndershield;
|
2013-01-10 16:06:39 -08:00
|
|
|
private $hunkStartLines;
|
2012-12-07 16:19:57 -08:00
|
|
|
private $oldLines;
|
|
|
|
private $newLines;
|
|
|
|
private $oldComments;
|
|
|
|
private $newComments;
|
|
|
|
private $oldChangesetID;
|
|
|
|
private $newChangesetID;
|
|
|
|
private $oldAttachesToNewFile;
|
|
|
|
private $newAttachesToNewFile;
|
|
|
|
private $highlightOld = array();
|
|
|
|
private $highlightNew = array();
|
|
|
|
private $codeCoverage;
|
|
|
|
private $handles;
|
|
|
|
private $markupEngine;
|
|
|
|
private $oldRender;
|
|
|
|
private $newRender;
|
|
|
|
private $originalOld;
|
|
|
|
private $originalNew;
|
2012-12-11 17:16:11 -08:00
|
|
|
private $gaps;
|
|
|
|
private $mask;
|
2014-06-20 11:49:41 -07:00
|
|
|
private $originalCharacterEncoding;
|
2015-01-30 11:17:34 -08:00
|
|
|
private $showEditAndReplyLinks;
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-09 18:41:47 -07:00
|
|
|
private $canMarkDone;
|
2015-03-27 11:23:10 -07:00
|
|
|
private $objectOwnerPHID;
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 12:07:46 -07:00
|
|
|
private $highlightingDisabled;
|
2019-02-20 05:06:42 -08:00
|
|
|
private $scopeEngine = false;
|
Render indent depth changes more clearly
Summary:
Ref T13161. See PHI723. Our whitespace handling is based on whitespace flags like `diff -bw`, mostly just for historical reasons: long ago, the easiest way to minimize the visual impact of indentation changes was to literally use `diff -bw`.
However, this approach is very coarse and has a lot of problems, like detecting `"ab" -> "a b"` as "only a whitespace change" even though this is always semantic. It also causes problems in YAML, Python, etc. Over time, we've added a lot of stuff to mitigate the downsides to this approach.
We also no longer get any benefits from this approach being simple: we need faithful diffs as the authoritative source, and have to completely rebuild the diff to `diff -bw` it. In the UI, we have a "whitespace mode" flag. We have the "whitespace matters" configuration.
I think ReviewBoard generally has a better approach to indent depth changes than we do (see T13161) where it detects them and renders them in a minimal way with low visual impact. This is ultimately what we want: reduce visual clutter for depth-only changes, but preserve whitespace changes in strings, etc.
Move toward detecting and rendering indent depth changes. Followup work:
- These should get colorblind colors and the design can probably use a little more tweaking.
- The OneUp mode is okay, but could be improved.
- Whitespace mode can now be removed completely.
- I'm trying to handle tabs correctly, but since we currently mangle them into spaces today, it's hard to be sure I actually got it right.
Test Plan: {F6214084}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161
Differential Revision: https://secure.phabricator.com/D20181
2019-02-15 08:10:56 -08:00
|
|
|
private $depthOnlyLines;
|
2019-09-27 16:11:39 -07:00
|
|
|
|
|
|
|
private $documentEngine;
|
2019-09-27 13:14:45 -07:00
|
|
|
private $documentEngineBlocks;
|
2014-06-20 11:49:41 -07:00
|
|
|
|
2014-08-13 14:41:06 -07:00
|
|
|
private $oldFile = false;
|
|
|
|
private $newFile = false;
|
|
|
|
|
Make "Show Context" persist rendering, whitespace, encoding, etc
Summary:
Ref T2009. Currently, we do not persist view parameters when making context rendering requests.
The big one is the renderer (1up vs 2up). This makes context on unified diffs come in with too many columns.
However, it impacts other parameters too. For example, at HEAD, if you change highlighting to "rainbow" and then load more context, the context uses the original highlighter instead of the rainbow highlighter.
This moves context loads into ChangesetViewManager, which maintains view parameters and can provide them correctly.
- This removes "ref"; it is no longer required, as the ChangesetViewManager tracks it.
- This removes URI management from `behavior-show-more`; it is no longer required, since the ChangesetViewManager knows how to render.
- This removes "whitespace" since this is handled properly by the view manager.
Test Plan:
- Used "Show Top" / "Show All" / "Show Bottom" in 1-up and 2-up views.
- Changed file highlighting to rainbow, loaded stuff, saw rainbow stick.
- Used "Show Entire File" in 1-up and 2-up views.
- Saw loading chrome.
- No loading chrome normally.
- Made inlines, verified `copyRows()` code runs.
- Poked around Diffusion -- it is missing some parameter handling, but works OK.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11977
2015-03-05 14:03:00 -08:00
|
|
|
abstract public function getRendererKey();
|
|
|
|
|
2015-01-30 11:17:34 -08:00
|
|
|
public function setShowEditAndReplyLinks($bool) {
|
|
|
|
$this->showEditAndReplyLinks = $bool;
|
|
|
|
return $this;
|
|
|
|
}
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 12:07:46 -07:00
|
|
|
|
2015-01-30 11:17:34 -08:00
|
|
|
public function getShowEditAndReplyLinks() {
|
|
|
|
return $this->showEditAndReplyLinks;
|
|
|
|
}
|
|
|
|
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 12:07:46 -07:00
|
|
|
public function setHighlightingDisabled($highlighting_disabled) {
|
|
|
|
$this->highlightingDisabled = $highlighting_disabled;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getHighlightingDisabled() {
|
|
|
|
return $this->highlightingDisabled;
|
|
|
|
}
|
|
|
|
|
2014-06-20 11:49:41 -07:00
|
|
|
public function setOriginalCharacterEncoding($original_character_encoding) {
|
|
|
|
$this->originalCharacterEncoding = $original_character_encoding;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getOriginalCharacterEncoding() {
|
|
|
|
return $this->originalCharacterEncoding;
|
|
|
|
}
|
2012-12-11 17:16:11 -08:00
|
|
|
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 12:07:46 -07:00
|
|
|
public function setIsUndershield($is_undershield) {
|
|
|
|
$this->isUndershield = $is_undershield;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getIsUndershield() {
|
|
|
|
return $this->isUndershield;
|
|
|
|
}
|
|
|
|
|
2012-12-11 17:16:11 -08:00
|
|
|
public function setMask($mask) {
|
|
|
|
$this->mask = $mask;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getMask() {
|
|
|
|
return $this->mask;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setGaps($gaps) {
|
|
|
|
$this->gaps = $gaps;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getGaps() {
|
|
|
|
return $this->gaps;
|
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Render indent depth changes more clearly
Summary:
Ref T13161. See PHI723. Our whitespace handling is based on whitespace flags like `diff -bw`, mostly just for historical reasons: long ago, the easiest way to minimize the visual impact of indentation changes was to literally use `diff -bw`.
However, this approach is very coarse and has a lot of problems, like detecting `"ab" -> "a b"` as "only a whitespace change" even though this is always semantic. It also causes problems in YAML, Python, etc. Over time, we've added a lot of stuff to mitigate the downsides to this approach.
We also no longer get any benefits from this approach being simple: we need faithful diffs as the authoritative source, and have to completely rebuild the diff to `diff -bw` it. In the UI, we have a "whitespace mode" flag. We have the "whitespace matters" configuration.
I think ReviewBoard generally has a better approach to indent depth changes than we do (see T13161) where it detects them and renders them in a minimal way with low visual impact. This is ultimately what we want: reduce visual clutter for depth-only changes, but preserve whitespace changes in strings, etc.
Move toward detecting and rendering indent depth changes. Followup work:
- These should get colorblind colors and the design can probably use a little more tweaking.
- The OneUp mode is okay, but could be improved.
- Whitespace mode can now be removed completely.
- I'm trying to handle tabs correctly, but since we currently mangle them into spaces today, it's hard to be sure I actually got it right.
Test Plan: {F6214084}
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T13161
Differential Revision: https://secure.phabricator.com/D20181
2019-02-15 08:10:56 -08:00
|
|
|
public function setDepthOnlyLines(array $lines) {
|
|
|
|
$this->depthOnlyLines = $lines;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getDepthOnlyLines() {
|
|
|
|
return $this->depthOnlyLines;
|
|
|
|
}
|
|
|
|
|
2014-08-13 14:41:06 -07:00
|
|
|
public function attachOldFile(PhabricatorFile $old = null) {
|
|
|
|
$this->oldFile = $old;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getOldFile() {
|
|
|
|
if ($this->oldFile === false) {
|
|
|
|
throw new PhabricatorDataNotAttachedException($this);
|
|
|
|
}
|
|
|
|
return $this->oldFile;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasOldFile() {
|
|
|
|
return (bool)$this->oldFile;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function attachNewFile(PhabricatorFile $new = null) {
|
|
|
|
$this->newFile = $new;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getNewFile() {
|
|
|
|
if ($this->newFile === false) {
|
|
|
|
throw new PhabricatorDataNotAttachedException($this);
|
|
|
|
}
|
|
|
|
return $this->newFile;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasNewFile() {
|
|
|
|
return (bool)$this->newFile;
|
|
|
|
}
|
|
|
|
|
2012-12-07 16:19:57 -08:00
|
|
|
public function setOriginalNew($original_new) {
|
|
|
|
$this->originalNew = $original_new;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getOriginalNew() {
|
|
|
|
return $this->originalNew;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setOriginalOld($original_old) {
|
|
|
|
$this->originalOld = $original_old;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getOriginalOld() {
|
|
|
|
return $this->originalOld;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setNewRender($new_render) {
|
|
|
|
$this->newRender = $new_render;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getNewRender() {
|
|
|
|
return $this->newRender;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setOldRender($old_render) {
|
|
|
|
$this->oldRender = $old_render;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getOldRender() {
|
|
|
|
return $this->oldRender;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setMarkupEngine(PhabricatorMarkupEngine $markup_engine) {
|
|
|
|
$this->markupEngine = $markup_engine;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
public function getMarkupEngine() {
|
|
|
|
return $this->markupEngine;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setHandles(array $handles) {
|
|
|
|
assert_instances_of($handles, 'PhabricatorObjectHandle');
|
|
|
|
$this->handles = $handles;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getHandles() {
|
|
|
|
return $this->handles;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setCodeCoverage($code_coverage) {
|
|
|
|
$this->codeCoverage = $code_coverage;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getCodeCoverage() {
|
|
|
|
return $this->codeCoverage;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setHighlightNew($highlight_new) {
|
|
|
|
$this->highlightNew = $highlight_new;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getHighlightNew() {
|
|
|
|
return $this->highlightNew;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setHighlightOld($highlight_old) {
|
|
|
|
$this->highlightOld = $highlight_old;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getHighlightOld() {
|
|
|
|
return $this->highlightOld;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setNewAttachesToNewFile($attaches) {
|
|
|
|
$this->newAttachesToNewFile = $attaches;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getNewAttachesToNewFile() {
|
|
|
|
return $this->newAttachesToNewFile;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setOldAttachesToNewFile($attaches) {
|
|
|
|
$this->oldAttachesToNewFile = $attaches;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getOldAttachesToNewFile() {
|
|
|
|
return $this->oldAttachesToNewFile;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setNewChangesetID($new_changeset_id) {
|
|
|
|
$this->newChangesetID = $new_changeset_id;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getNewChangesetID() {
|
|
|
|
return $this->newChangesetID;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setOldChangesetID($old_changeset_id) {
|
|
|
|
$this->oldChangesetID = $old_changeset_id;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getOldChangesetID() {
|
|
|
|
return $this->oldChangesetID;
|
|
|
|
}
|
|
|
|
|
2019-09-27 16:11:39 -07:00
|
|
|
public function setDocumentEngine(PhabricatorDocumentEngine $engine) {
|
|
|
|
$this->documentEngine = $engine;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getDocumentEngine() {
|
|
|
|
return $this->documentEngine;
|
|
|
|
}
|
|
|
|
|
2019-09-27 13:14:45 -07:00
|
|
|
public function setDocumentEngineBlocks(
|
|
|
|
PhabricatorDocumentEngineBlocks $blocks) {
|
|
|
|
$this->documentEngineBlocks = $blocks;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getDocumentEngineBlocks() {
|
|
|
|
return $this->documentEngineBlocks;
|
|
|
|
}
|
|
|
|
|
2012-12-07 16:19:57 -08:00
|
|
|
public function setNewComments(array $new_comments) {
|
|
|
|
foreach ($new_comments as $line_number => $comments) {
|
Make "editing" state persistent for inline comments
Summary:
Ref T13513. This is mostly an infrastructure cleanup change.
In a perfect world, this would be a series of several changes, but they're tightly interconnected and don't have an obvious clean, nontrivial partition (or, at least, I don't see one). Followup changes will exercise this code repeatedly and all of these individual mutations are "obviously good", so I'm not too worried about the breadth of this change.
---
Inline comments are stored as transaction comments in the `PhabricatorAuditTransactionComment` and `DifferentialTransactionComment` classes.
On top of these two storage classes sit `PhabricatorAuditInlineComment` and `DifferentialInlineComment`. Historically, these were an indirection layer over significantly different storage classes, but nowadays both storage classes look pretty similar and most of the logic is actually the same. Prior to this change, these two classes were about 80% copy/pastes of one another.
Part of the reason they're so copy/pastey is that they implement a parent `Interface`. They are the only classes which implement this interface, and the interface does not provide any correctness guarantees (the storage objects are not actually constrained by it).
To simplify this:
- Make `PhabricatorInlineCommentInterface` an abstract base class instead.
- Lift as much code out of the `Audit` and `Differential` subclasses as possible.
- Delete methods which no longer have callers, or have only trivial callers.
---
Inline comments have two `View` rendering classes, `DetailView` and `EditView`. They share very little code.
Partly, this is because `EditView` does not take an `$inline` object. Historically, it needed to be able to operate on inlines that did not have an ID yet, and even further back in history this was probably just an outgrowth of a simple `<form />`.
These classes can be significantly simplified by passing an `$inline` to the `EditView`, instead of individually setting all the properties on the `View` itself. This allows the `DetailView` and `EditView` classes to share a lot of code.
The `EditView` can not fully render its content. Move the content rendering code into the view.
---
Prior to this change, some operations need to work on inlines that don't have an inline ID yet (we assign an ID the first time you "Save" a comment). Since "editing" comments will now be saved, we can instead create a row immediately.
This means that all the inline code can always rely on having a valid ID to work with, even if that ID corresponds to an empty, draft, "isEditing" comment. This simplifies more code in `EditView` and allows the "create" and "reply" code to be merged in `PhabricatorInlineCommentController`.
---
Client-side inline events are currently handled through a mixture of `ChangesetList` listeners (good) and ad-hoc row-level listeners (less good). In particular, the "save", "cancel", and "undo" events are row-level. All other events are list-level.
Move all events to list-level. This is supported by all inlines now having an ID at all stages of their lifecycle.
This allows some of the client behavior to be simplified. It currently depends on binding complex ad-hoc dictionaries into event handlers in `_drawRows()`, but it seems like almost all of this code can be removed. In fact, no more than one row ever seems to be drawn, so this code can probably be simplified further.
---
Finally, save an "isEditing" state. When we rebuild a revision on the client, click the "edit" button if it's in this state. This is a little hacky, but simpler to get into a stable state, since the row layout of an inline depends on a "view row" followed by an "edit row".
Test Plan:
- Created comments on either side of a diff.
- Edited a comment, reloaded, saw edit stick.
- Saved comments, reloaded, saw save stick.
- Edited a comment, typed text, cancelled, "unedited" to get state back.
- Created a comment, typed text, cancelled, "unedited" to get state back.
- Deleted a comment, "undeleted" to get state back.
Weirdness / known issues:
- Drafts don't autosave yet.
- Fixed in D21187:
- When you create an empty comment then reload, you get an empty editor. This is a bit silly.
- "Cancel" does not save state, but should, once drafts autosave.
- Mostly fixed in D21188:
- "Editing" comments aren't handled specially by the overall submission flow.
- "Editing" comments submitted in that state try to edit themselves again on load, which doesn't work.
Subscribers: jmeador
Maniphest Tasks: T13513
Differential Revision: https://secure.phabricator.com/D21186
2020-04-28 14:45:54 -07:00
|
|
|
assert_instances_of($comments, 'PhabricatorInlineComment');
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
|
|
|
$this->newComments = $new_comments;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getNewComments() {
|
|
|
|
return $this->newComments;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setOldComments(array $old_comments) {
|
|
|
|
foreach ($old_comments as $line_number => $comments) {
|
Make "editing" state persistent for inline comments
Summary:
Ref T13513. This is mostly an infrastructure cleanup change.
In a perfect world, this would be a series of several changes, but they're tightly interconnected and don't have an obvious clean, nontrivial partition (or, at least, I don't see one). Followup changes will exercise this code repeatedly and all of these individual mutations are "obviously good", so I'm not too worried about the breadth of this change.
---
Inline comments are stored as transaction comments in the `PhabricatorAuditTransactionComment` and `DifferentialTransactionComment` classes.
On top of these two storage classes sit `PhabricatorAuditInlineComment` and `DifferentialInlineComment`. Historically, these were an indirection layer over significantly different storage classes, but nowadays both storage classes look pretty similar and most of the logic is actually the same. Prior to this change, these two classes were about 80% copy/pastes of one another.
Part of the reason they're so copy/pastey is that they implement a parent `Interface`. They are the only classes which implement this interface, and the interface does not provide any correctness guarantees (the storage objects are not actually constrained by it).
To simplify this:
- Make `PhabricatorInlineCommentInterface` an abstract base class instead.
- Lift as much code out of the `Audit` and `Differential` subclasses as possible.
- Delete methods which no longer have callers, or have only trivial callers.
---
Inline comments have two `View` rendering classes, `DetailView` and `EditView`. They share very little code.
Partly, this is because `EditView` does not take an `$inline` object. Historically, it needed to be able to operate on inlines that did not have an ID yet, and even further back in history this was probably just an outgrowth of a simple `<form />`.
These classes can be significantly simplified by passing an `$inline` to the `EditView`, instead of individually setting all the properties on the `View` itself. This allows the `DetailView` and `EditView` classes to share a lot of code.
The `EditView` can not fully render its content. Move the content rendering code into the view.
---
Prior to this change, some operations need to work on inlines that don't have an inline ID yet (we assign an ID the first time you "Save" a comment). Since "editing" comments will now be saved, we can instead create a row immediately.
This means that all the inline code can always rely on having a valid ID to work with, even if that ID corresponds to an empty, draft, "isEditing" comment. This simplifies more code in `EditView` and allows the "create" and "reply" code to be merged in `PhabricatorInlineCommentController`.
---
Client-side inline events are currently handled through a mixture of `ChangesetList` listeners (good) and ad-hoc row-level listeners (less good). In particular, the "save", "cancel", and "undo" events are row-level. All other events are list-level.
Move all events to list-level. This is supported by all inlines now having an ID at all stages of their lifecycle.
This allows some of the client behavior to be simplified. It currently depends on binding complex ad-hoc dictionaries into event handlers in `_drawRows()`, but it seems like almost all of this code can be removed. In fact, no more than one row ever seems to be drawn, so this code can probably be simplified further.
---
Finally, save an "isEditing" state. When we rebuild a revision on the client, click the "edit" button if it's in this state. This is a little hacky, but simpler to get into a stable state, since the row layout of an inline depends on a "view row" followed by an "edit row".
Test Plan:
- Created comments on either side of a diff.
- Edited a comment, reloaded, saw edit stick.
- Saved comments, reloaded, saw save stick.
- Edited a comment, typed text, cancelled, "unedited" to get state back.
- Created a comment, typed text, cancelled, "unedited" to get state back.
- Deleted a comment, "undeleted" to get state back.
Weirdness / known issues:
- Drafts don't autosave yet.
- Fixed in D21187:
- When you create an empty comment then reload, you get an empty editor. This is a bit silly.
- "Cancel" does not save state, but should, once drafts autosave.
- Mostly fixed in D21188:
- "Editing" comments aren't handled specially by the overall submission flow.
- "Editing" comments submitted in that state try to edit themselves again on load, which doesn't work.
Subscribers: jmeador
Maniphest Tasks: T13513
Differential Revision: https://secure.phabricator.com/D21186
2020-04-28 14:45:54 -07:00
|
|
|
assert_instances_of($comments, 'PhabricatorInlineComment');
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
|
|
|
$this->oldComments = $old_comments;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getOldComments() {
|
|
|
|
return $this->oldComments;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setNewLines(array $new_lines) {
|
|
|
|
$this->newLines = $new_lines;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getNewLines() {
|
|
|
|
return $this->newLines;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setOldLines(array $old_lines) {
|
|
|
|
$this->oldLines = $old_lines;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getOldLines() {
|
|
|
|
return $this->oldLines;
|
|
|
|
}
|
|
|
|
|
2013-01-10 16:06:39 -08:00
|
|
|
public function setHunkStartLines(array $hunk_start_lines) {
|
|
|
|
$this->hunkStartLines = $hunk_start_lines;
|
2012-12-07 16:19:57 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2013-01-10 16:06:39 -08:00
|
|
|
protected function getHunkStartLines() {
|
|
|
|
return $this->hunkStartLines;
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
public function setUser(PhabricatorUser $user) {
|
|
|
|
$this->user = $user;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getUser() {
|
|
|
|
return $this->user;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setChangeset(DifferentialChangeset $changeset) {
|
|
|
|
$this->changeset = $changeset;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getChangeset() {
|
|
|
|
return $this->changeset;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setRenderingReference($rendering_reference) {
|
|
|
|
$this->renderingReference = $rendering_reference;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
protected function getRenderingReference() {
|
|
|
|
return $this->renderingReference;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function setRenderPropertyChangeHeader($should_render) {
|
|
|
|
$this->renderPropertyChangeHeader = $should_render;
|
|
|
|
return $this;
|
|
|
|
}
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-09 18:41:47 -07:00
|
|
|
|
2012-12-07 16:19:57 -08:00
|
|
|
private function shouldRenderPropertyChangeHeader() {
|
|
|
|
return $this->renderPropertyChangeHeader;
|
|
|
|
}
|
|
|
|
|
2013-09-12 16:00:00 -07:00
|
|
|
public function setIsTopLevel($is) {
|
|
|
|
$this->isTopLevel = $is;
|
|
|
|
return $this;
|
|
|
|
}
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-09 18:41:47 -07:00
|
|
|
|
2013-09-12 16:00:00 -07:00
|
|
|
private function getIsTopLevel() {
|
|
|
|
return $this->isTopLevel;
|
|
|
|
}
|
|
|
|
|
Track a "Done" state on inline comments
Summary:
Ref T1460. This just barely works, but throwing it up in case any of it sounds mechanically crazy before we build integrations/UI/etc.
Specifically, these are the behaviors:
- You can mark your own draft comments as "done" before you submit them. The intent is to let reviewers mark their stuff advisory/minor/not-important before they submit it, to hint to authors that they don't expect the feedback to necessarily be addressed (maybe it's a joke, maybe it's just discussion, maybe it's "consider..").
- You can mark others' published comments as "done" if you're the revision/commit author. The intent is to keep this lightweight by not requiring an audit trail of who marked what done when. If anyone could mark anything done, we'd have to have some way to show who marked stuff.
- When you mark stuff done (or unmark it), it goes into a "draft" state, where you see the change but others don't see it yet. The intent is twofold:
- Be consistent with how inlines work.
- Allow us to publish a "epriestley updated this revision + epriestley marked 15 inlines as done" story later if we want. This seems more useful than publishing 15 "epriestley marked one thing as done" stories.
- The actual bit where done-ness publishes isn't implemented.
- UI is bare bones.
- No integration with the rest of the UI yet.
Test Plan: Clicked some checkboxes.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: paulshen, chasemp, epriestley
Maniphest Tasks: T1460
Differential Revision: https://secure.phabricator.com/D12033
2015-03-09 18:41:47 -07:00
|
|
|
public function setCanMarkDone($can_mark_done) {
|
|
|
|
$this->canMarkDone = $can_mark_done;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getCanMarkDone() {
|
|
|
|
return $this->canMarkDone;
|
|
|
|
}
|
|
|
|
|
2015-03-27 11:23:10 -07:00
|
|
|
public function setObjectOwnerPHID($phid) {
|
|
|
|
$this->objectOwnerPHID = $phid;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getObjectOwnerPHID() {
|
|
|
|
return $this->objectOwnerPHID;
|
|
|
|
}
|
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
final public function renderChangesetTable($content) {
|
|
|
|
$props = null;
|
|
|
|
if ($this->shouldRenderPropertyChangeHeader()) {
|
|
|
|
$props = $this->renderPropertyChangeHeader();
|
|
|
|
}
|
|
|
|
|
2013-09-12 16:00:00 -07:00
|
|
|
$notice = null;
|
|
|
|
if ($this->getIsTopLevel()) {
|
|
|
|
$force = (!$content && !$props);
|
2019-09-27 13:14:45 -07:00
|
|
|
|
|
|
|
// If we have DocumentEngine messages about the blocks, assume they
|
|
|
|
// explain why there's no content.
|
|
|
|
$blocks = $this->getDocumentEngineBlocks();
|
|
|
|
if ($blocks) {
|
|
|
|
if ($blocks->getMessages()) {
|
|
|
|
$force = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-12 16:00:00 -07:00
|
|
|
$notice = $this->renderChangeTypeHeader($force);
|
|
|
|
}
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 12:07:46 -07:00
|
|
|
$undershield = null;
|
|
|
|
if ($this->getIsUndershield()) {
|
|
|
|
$undershield = $this->renderUndershieldHeader();
|
|
|
|
}
|
|
|
|
|
Display some invisible/nonprintable characters in diffs by default
Summary:
Ref T12822. Ref T2495. This is the good version of D20193.
Currently, we display various nonprintable characters (ZWS, nonbreaking space, various control characters) as themselves, so they're generally invisible.
In T12822, one user reports that all their engineers frequently type ZWS characters into source somehow? I don't really believe this (??), and this should be fixed in lint.
That said, the only real reason not to show these weird characters in a special way was that it would break copy/paste: if we render ZWS as "🐑", and a user copy-pastes the line including the ZWS, they'll get a sheep.
At least, they would have, until D20191. Now that this whole thing is end-to-end Javascript magic, we can copy whatever we want.
In particular, we can render any character `X` as `<span data-copy-text="Y">X</span>`, and then copy "Y" instead of "X" when the user copies the node. Limitations:
- If users select only "X", they'll get "X" on their clipboard. This seems fine. If you're selecting our ZWS marker *only*, you probably want to copy it?
- If "X" is more than one character long, users will get the full "Y" if they select any part of "X". At least here, this only matters when "X" is several spaces and "Y" is a tab. This also seems fine.
- We have to be kind of careful because this approach involves editing an HTML blob directly. However, we already do that elsewhere and this isn't really too hard to get right.
With those tools in hand:
- Replace "\t" (raw text / what gets copied) with the number of spaces to the next tab stop for display.
- Replace ZWS and NBSP (raw text) with a special marker for display.
- Replace control characters 0x00-0x19 and 0x7F, except for "\t", "\r", and "\n", with the special unicode "control character pictures" reserved for this purpose.
Test Plan:
- Generated and viewed a file like this one:
{F6220422}
- Copied text out of it, got authentic raw original source text instead of displayed text.
Reviewers: amckinley
Reviewed By: amckinley
Maniphest Tasks: T12822, T2495
Differential Revision: https://secure.phabricator.com/D20194
2019-02-17 13:39:46 -08:00
|
|
|
$result = array(
|
|
|
|
$notice,
|
|
|
|
$props,
|
|
|
|
$undershield,
|
|
|
|
$content,
|
|
|
|
);
|
|
|
|
|
|
|
|
return hsprintf('%s', $result);
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
abstract public function isOneUpRenderer();
|
2012-12-07 16:19:57 -08:00
|
|
|
abstract public function renderTextChange(
|
|
|
|
$range_start,
|
|
|
|
$range_len,
|
2013-02-19 13:47:03 -08:00
|
|
|
$rows);
|
2019-09-23 11:09:29 -07:00
|
|
|
|
|
|
|
public function renderDocumentEngineBlocks(
|
|
|
|
PhabricatorDocumentEngineBlocks $blocks,
|
|
|
|
$old_changeset_key,
|
|
|
|
$new_changeset_key) {
|
|
|
|
return null;
|
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
abstract protected function renderChangeTypeHeader($force);
|
Don't highlight very large files by default
Summary:
Ref T5644. See some discussion in D8040.
When a file is very large (more than 64KB of text), don't activate syntax highlighting by default. This should prevent us from wasting resources running `pygmentize` on enormous files.
Users who want the file highlighted can still select "Highlight As...".
The tricky part of this diff is separating the headers into "changeset" headers and "undershield" (rendering) headers. Specifically, a file might have these headers/shields:
- "This file is newly added."
- "This file is generated. Show Changes"
- "Highlighting is disabled for this large file."
In this case, I want the user to see "added" and "generated" when they load the page, and only see "highlighting disabled" after they click "Show Changes". So there are several categories:
- "Changeset" headers, which discuss the changeset as a whole (binary file, image file, moved, added, deleted, etc.)
- "Property" headers, which describe metadata changes (not relevant here).
- "Shields", which hide files from view by default.
- "Undershield" headers, which provide rendering information that is only relevant if there is no shield on the file.
Test Plan:
- Viewed a diff with the library map, clicked "show changes", got a "highlighting disabled" header back with highlighting disabled.
- Enabled highlighting explicitly (this currently restores the shield, which it probably shouldn't, but that feels out of scope for this change). The deshielded file is highlighted per the user's request.
- Loaded context on normal files.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: joshuaspence, epriestley
Maniphest Tasks: T5644
Differential Revision: https://secure.phabricator.com/D12132
2014-06-29 12:07:46 -07:00
|
|
|
abstract protected function renderUndershieldHeader();
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
|
|
|
|
protected function didRenderChangesetTableContents($contents) {
|
|
|
|
return $contents;
|
|
|
|
}
|
|
|
|
|
Fix whitespace and unchanged file shields
Summary:
Fixes T181. I actually have no idea what the original issue in T181 was, but this fixes several problems:
- The code for figuring out whitespace-only changes was extremely confusing and probably buggy (the code for figuring out unchanged files was equally confusing but probably less buggy).
- When rendering a whitespace shield, we did not offer a "Show Changes" link. Instead, show the "Show Changes" link: we can always render the content beneath this link.
- When clicking "Show Changes", we used the current whitespace mode, which might result in a diff with no changes. Instead, force "show all" whitespace mode.
- We never offered a "show changes" link for unchanged files. Instead, offer this link if we can service it.
- When clicking "Show Changes", we pierced the shield but didn't force file content, which would fold the entire file even if it was available. Instead, force the file content.
Test Plan: Generated whitespace-only and no-change diffs. Clicked shield links, or verified no shield link available in no-change-with-no-content. Generated an "@generated" change, verified shield worked correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T181, T2009
Differential Revision: https://secure.phabricator.com/D4407
2013-01-11 15:27:42 -08:00
|
|
|
/**
|
|
|
|
* Render a "shield" over the diff, with a message like "This file is
|
|
|
|
* generated and does not need to be reviewed." or "This file was completely
|
|
|
|
* deleted." This UI element hides unimportant text so the reviewer doesn't
|
|
|
|
* need to scroll past it.
|
|
|
|
*
|
|
|
|
* The shield includes a link to view the underlying content. This link
|
|
|
|
* may force certain rendering modes when the link is clicked:
|
|
|
|
*
|
|
|
|
* - `"default"`: Render the diff normally, as though it was not
|
|
|
|
* shielded. This is the default and appropriate if the underlying
|
|
|
|
* diff is a normal change, but was hidden for reasons of not being
|
|
|
|
* important (e.g., generated code).
|
|
|
|
* - `"text"`: Force the text to be shown. This is probably only relevant
|
|
|
|
* when a file is not changed.
|
|
|
|
* - `"none"`: Don't show the link (e.g., text not available).
|
|
|
|
*
|
|
|
|
* @param string Message explaining why the diff is hidden.
|
|
|
|
* @param string|null Force mode, see above.
|
|
|
|
* @return string Shield markup.
|
|
|
|
*/
|
2013-01-14 14:20:54 -08:00
|
|
|
abstract public function renderShield($message, $force = 'default');
|
Fix whitespace and unchanged file shields
Summary:
Fixes T181. I actually have no idea what the original issue in T181 was, but this fixes several problems:
- The code for figuring out whitespace-only changes was extremely confusing and probably buggy (the code for figuring out unchanged files was equally confusing but probably less buggy).
- When rendering a whitespace shield, we did not offer a "Show Changes" link. Instead, show the "Show Changes" link: we can always render the content beneath this link.
- When clicking "Show Changes", we used the current whitespace mode, which might result in a diff with no changes. Instead, force "show all" whitespace mode.
- We never offered a "show changes" link for unchanged files. Instead, offer this link if we can service it.
- When clicking "Show Changes", we pierced the shield but didn't force file content, which would fold the entire file even if it was available. Instead, force the file content.
Test Plan: Generated whitespace-only and no-change diffs. Clicked shield links, or verified no shield link available in no-change-with-no-content. Generated an "@generated" change, verified shield worked correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T181, T2009
Differential Revision: https://secure.phabricator.com/D4407
2013-01-11 15:27:42 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
abstract protected function renderPropertyChangeHeader();
|
Fix whitespace and unchanged file shields
Summary:
Fixes T181. I actually have no idea what the original issue in T181 was, but this fixes several problems:
- The code for figuring out whitespace-only changes was extremely confusing and probably buggy (the code for figuring out unchanged files was equally confusing but probably less buggy).
- When rendering a whitespace shield, we did not offer a "Show Changes" link. Instead, show the "Show Changes" link: we can always render the content beneath this link.
- When clicking "Show Changes", we used the current whitespace mode, which might result in a diff with no changes. Instead, force "show all" whitespace mode.
- We never offered a "show changes" link for unchanged files. Instead, offer this link if we can service it.
- When clicking "Show Changes", we pierced the shield but didn't force file content, which would fold the entire file even if it was available. Instead, force the file content.
Test Plan: Generated whitespace-only and no-change diffs. Clicked shield links, or verified no shield link available in no-change-with-no-content. Generated an "@generated" change, verified shield worked correctly.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T181, T2009
Differential Revision: https://secure.phabricator.com/D4407
2013-01-11 15:27:42 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
protected function buildPrimitives($range_start, $range_len) {
|
|
|
|
$primitives = array();
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$hunk_starts = $this->getHunkStartLines();
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$mask = $this->getMask();
|
|
|
|
$gaps = $this->getGaps();
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$old = $this->getOldLines();
|
|
|
|
$new = $this->getNewLines();
|
|
|
|
$old_render = $this->getOldRender();
|
|
|
|
$new_render = $this->getNewRender();
|
|
|
|
$old_comments = $this->getOldComments();
|
|
|
|
$new_comments = $this->getNewComments();
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$size = count($old);
|
|
|
|
for ($ii = $range_start; $ii < $range_start + $range_len; $ii++) {
|
|
|
|
if (empty($mask[$ii])) {
|
|
|
|
list($top, $len) = array_pop($gaps);
|
|
|
|
$primitives[] = array(
|
|
|
|
'type' => 'context',
|
|
|
|
'top' => $top,
|
|
|
|
'len' => $len,
|
|
|
|
);
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$ii += ($len - 1);
|
|
|
|
continue;
|
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$ospec = array(
|
|
|
|
'type' => 'old',
|
|
|
|
'htype' => null,
|
|
|
|
'cursor' => $ii,
|
|
|
|
'line' => null,
|
2013-01-14 14:20:35 -08:00
|
|
|
'oline' => null,
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
'render' => null,
|
|
|
|
);
|
|
|
|
|
|
|
|
$nspec = array(
|
|
|
|
'type' => 'new',
|
|
|
|
'htype' => null,
|
|
|
|
'cursor' => $ii,
|
|
|
|
'line' => null,
|
2013-01-14 14:20:35 -08:00
|
|
|
'oline' => null,
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
'render' => null,
|
|
|
|
'copy' => null,
|
|
|
|
'coverage' => null,
|
|
|
|
);
|
|
|
|
|
|
|
|
if (isset($old[$ii])) {
|
2013-01-14 14:20:35 -08:00
|
|
|
$ospec['line'] = (int)$old[$ii]['line'];
|
|
|
|
$nspec['oline'] = (int)$old[$ii]['line'];
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$ospec['htype'] = $old[$ii]['type'];
|
|
|
|
if (isset($old_render[$ii])) {
|
|
|
|
$ospec['render'] = $old_render[$ii];
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
if (isset($new[$ii])) {
|
2013-01-14 14:20:35 -08:00
|
|
|
$nspec['line'] = (int)$new[$ii]['line'];
|
|
|
|
$ospec['oline'] = (int)$new[$ii]['line'];
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$nspec['htype'] = $new[$ii]['type'];
|
|
|
|
if (isset($new_render[$ii])) {
|
|
|
|
$nspec['render'] = $new_render[$ii];
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
if (isset($hunk_starts[$ospec['line']])) {
|
|
|
|
$primitives[] = array(
|
|
|
|
'type' => 'no-context',
|
|
|
|
);
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$primitives[] = $ospec;
|
|
|
|
$primitives[] = $nspec;
|
|
|
|
|
|
|
|
if ($ospec['line'] !== null && isset($old_comments[$ospec['line']])) {
|
|
|
|
foreach ($old_comments[$ospec['line']] as $comment) {
|
|
|
|
$primitives[] = array(
|
|
|
|
'type' => 'inline',
|
|
|
|
'comment' => $comment,
|
|
|
|
'right' => false,
|
|
|
|
);
|
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
|
|
|
|
if ($nspec['line'] !== null && isset($new_comments[$nspec['line']])) {
|
|
|
|
foreach ($new_comments[$nspec['line']] as $comment) {
|
|
|
|
$primitives[] = array(
|
|
|
|
'type' => 'inline',
|
2013-01-14 14:20:35 -08:00
|
|
|
'comment' => $comment,
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
'right' => true,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($hunk_starts && ($ii == $size - 1)) {
|
|
|
|
$primitives[] = array(
|
|
|
|
'type' => 'no-context',
|
|
|
|
);
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
if ($this->isOneUpRenderer()) {
|
|
|
|
$primitives = $this->processPrimitivesForOneUp($primitives);
|
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
return $primitives;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function processPrimitivesForOneUp(array $primitives) {
|
|
|
|
// Primitives come out of buildPrimitives() in two-up format, because it
|
|
|
|
// is the most general, flexible format. To put them into one-up format,
|
|
|
|
// we need to filter and reorder them. In particular:
|
|
|
|
//
|
|
|
|
// - We discard unchanged lines in the old file; in one-up format, we
|
|
|
|
// render them only once.
|
|
|
|
// - We group contiguous blocks of old-modified and new-modified lines, so
|
|
|
|
// they render in "block of old, block of new" order instead of
|
|
|
|
// alternating old and new lines.
|
|
|
|
|
|
|
|
$out = array();
|
|
|
|
|
|
|
|
$old_buf = array();
|
|
|
|
$new_buf = array();
|
|
|
|
foreach ($primitives as $primitive) {
|
|
|
|
$type = $primitive['type'];
|
2013-01-14 14:20:35 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
if ($type == 'old') {
|
|
|
|
if (!$primitive['htype']) {
|
|
|
|
// This is a line which appears in both the old file and the new
|
|
|
|
// file, or the spacer corresponding to a line added in the new file.
|
|
|
|
// Ignore it when rendering a one-up diff.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
$old_buf[] = $primitive;
|
|
|
|
} else if ($type == 'new') {
|
|
|
|
if ($primitive['line'] === null) {
|
|
|
|
// This is an empty spacer corresponding to a line removed from the
|
|
|
|
// old file. Ignore it when rendering a one-up diff.
|
|
|
|
continue;
|
|
|
|
}
|
2015-03-05 14:04:21 -08:00
|
|
|
if (!$primitive['htype']) {
|
|
|
|
// If this line is the same in both versions of the file, put it in
|
|
|
|
// the old line buffer. This makes sure inlines on old, unchanged
|
|
|
|
// lines end up in the right place.
|
2015-03-05 16:24:04 -08:00
|
|
|
|
Further improve line grouping in unified views
Summary:
Ref T2009. This tweaks things a bit more to improve consecuitive groups of added and removed lines.
Generally, it gives us "old, old, old, new, new, new" intead of "old, new, old, new, old, new".
Feelin' real good about having unit tests for this stuff.
Test Plan: Unit tests, looked at diffs in web UI.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11994
2015-03-06 09:58:26 -08:00
|
|
|
// First, we need to flush the line buffers if they're not empty.
|
|
|
|
if ($old_buf) {
|
|
|
|
$out[] = $old_buf;
|
|
|
|
$old_buf = array();
|
|
|
|
}
|
2015-03-05 16:24:04 -08:00
|
|
|
if ($new_buf) {
|
|
|
|
$out[] = $new_buf;
|
|
|
|
$new_buf = array();
|
|
|
|
}
|
2015-03-05 14:04:21 -08:00
|
|
|
$old_buf[] = $primitive;
|
|
|
|
} else {
|
|
|
|
$new_buf[] = $primitive;
|
|
|
|
}
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
} else if ($type == 'context' || $type == 'no-context') {
|
|
|
|
$out[] = $old_buf;
|
|
|
|
$out[] = $new_buf;
|
|
|
|
$old_buf = array();
|
|
|
|
$new_buf = array();
|
|
|
|
$out[] = array($primitive);
|
|
|
|
} else if ($type == 'inline') {
|
2015-03-05 14:11:36 -08:00
|
|
|
|
|
|
|
// If this inline is on the left side, put it after the old lines.
|
|
|
|
if (!$primitive['right']) {
|
|
|
|
$out[] = $old_buf;
|
|
|
|
$out[] = array($primitive);
|
Further improve line grouping in unified views
Summary:
Ref T2009. This tweaks things a bit more to improve consecuitive groups of added and removed lines.
Generally, it gives us "old, old, old, new, new, new" intead of "old, new, old, new, old, new".
Feelin' real good about having unit tests for this stuff.
Test Plan: Unit tests, looked at diffs in web UI.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11994
2015-03-06 09:58:26 -08:00
|
|
|
$old_buf = array();
|
2015-03-05 14:11:36 -08:00
|
|
|
} else {
|
|
|
|
$out[] = $old_buf;
|
|
|
|
$out[] = $new_buf;
|
|
|
|
$out[] = array($primitive);
|
Further improve line grouping in unified views
Summary:
Ref T2009. This tweaks things a bit more to improve consecuitive groups of added and removed lines.
Generally, it gives us "old, old, old, new, new, new" intead of "old, new, old, new, old, new".
Feelin' real good about having unit tests for this stuff.
Test Plan: Unit tests, looked at diffs in web UI.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D11994
2015-03-06 09:58:26 -08:00
|
|
|
$old_buf = array();
|
|
|
|
$new_buf = array();
|
2015-03-05 14:11:36 -08:00
|
|
|
}
|
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
} else {
|
2015-05-22 17:27:56 +10:00
|
|
|
throw new Exception(pht("Unknown primitive type '%s'!", $primitive));
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
}
|
|
|
|
}
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
$out[] = $old_buf;
|
|
|
|
$out[] = $new_buf;
|
|
|
|
$out = array_mergev($out);
|
2012-12-07 16:19:57 -08:00
|
|
|
|
Implement basic one-up and test renderers
Summary:
This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this:
- Renderer (more methods are abstract than before)
- HTML Renderer (most HTML stuff has moved down from the base to here)
- HTML 1-up (placeholder only -- not yet a functional implementation)
- HTML 2-up (minimal changes, uses mostly old code)
- Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff)
- Test 1-up (selects 1-up mode for test rendering)
- Test 2-up (selects 2-up mode for test rendering)
Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this:
- Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class.
- The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment).
- Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class.
- Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class.
The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics.
The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path.
Test Plan: Ran unit tests, looked at a bunch of diffs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2009
Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 14:20:06 -08:00
|
|
|
return $out;
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|
|
|
|
|
2014-08-13 14:41:06 -07:00
|
|
|
protected function getChangesetProperties($changeset) {
|
|
|
|
$old = $changeset->getOldProperties();
|
|
|
|
$new = $changeset->getNewProperties();
|
|
|
|
|
Improve the construction of synthetic "comparison/intradiff" changesets
Summary:
Ref T13523. Currently, when building a "comparison" changeset, metadata is taken from the left changeset. This is somewhat arbitrary.
This means that intradiffs of images don't work properly because the rendered changeset has only the left (usually "old") information.
Later, some of the code attempts to ignore the file data stored on the changeset and reconstruct the correct file data, which is how the result ends up not-completely-wrong.
Be more careful about building sensible-ish metadata, and then just use it directly later on. This fixes the "spooky" code referencing D955 + D6851.
There are some related issues, where "change type" and "file type" are selected arbitrarily and then used to determine whether the change has an "old/new" state or not (i.e., is the left side of the diff empty, since the change creates the file)?
In many cases, neither of the original changesets have a "change type" which will answer this question correctly. Separate this concept from "has state" from "change type", and make more of the code ask narrower questions about the specific conditions or states it cares about, rather than "change type".
Test Plan:
- Created a revision with Diff 1, Diff 2, and Diff 3. Diff 1 takes an image from "null -> A". Diff 2 takes the same image from "null -> B". Diff 3 takes the same image from "A -> B'.
- Intradiffed 1v2 and 1v3.
- Before patch:
- Left side usually missing, which is incorrect (should always be "A").
- Change properties are a mess ("null -> image/png" for MIME type, e.g.)
- Uninteresting/incorrect "unix:filemode" stuff.
- After patch;
- Left side shows state "A".
- Change properties only show size changes (which is correct).
{F7402012}
Maniphest Tasks: T13523
Differential Revision: https://secure.phabricator.com/D21180
2020-04-27 16:12:43 -07:00
|
|
|
// If a property has been changed, but is not present on one side of the
|
|
|
|
// change and has an uninteresting default value on the other, remove it.
|
|
|
|
// This most commonly happens when a change adds or removes a file: the
|
|
|
|
// side of the change with the file has a "100644" filemode in Git.
|
|
|
|
|
|
|
|
$defaults = array(
|
|
|
|
'unix:filemode' => '100644',
|
|
|
|
);
|
2014-08-13 14:41:06 -07:00
|
|
|
|
Improve the construction of synthetic "comparison/intradiff" changesets
Summary:
Ref T13523. Currently, when building a "comparison" changeset, metadata is taken from the left changeset. This is somewhat arbitrary.
This means that intradiffs of images don't work properly because the rendered changeset has only the left (usually "old") information.
Later, some of the code attempts to ignore the file data stored on the changeset and reconstruct the correct file data, which is how the result ends up not-completely-wrong.
Be more careful about building sensible-ish metadata, and then just use it directly later on. This fixes the "spooky" code referencing D955 + D6851.
There are some related issues, where "change type" and "file type" are selected arbitrarily and then used to determine whether the change has an "old/new" state or not (i.e., is the left side of the diff empty, since the change creates the file)?
In many cases, neither of the original changesets have a "change type" which will answer this question correctly. Separate this concept from "has state" from "change type", and make more of the code ask narrower questions about the specific conditions or states it cares about, rather than "change type".
Test Plan:
- Created a revision with Diff 1, Diff 2, and Diff 3. Diff 1 takes an image from "null -> A". Diff 2 takes the same image from "null -> B". Diff 3 takes the same image from "A -> B'.
- Intradiffed 1v2 and 1v3.
- Before patch:
- Left side usually missing, which is incorrect (should always be "A").
- Change properties are a mess ("null -> image/png" for MIME type, e.g.)
- Uninteresting/incorrect "unix:filemode" stuff.
- After patch;
- Left side shows state "A".
- Change properties only show size changes (which is correct).
{F7402012}
Maniphest Tasks: T13523
Differential Revision: https://secure.phabricator.com/D21180
2020-04-27 16:12:43 -07:00
|
|
|
foreach ($defaults as $default_key => $default_value) {
|
|
|
|
$old_value = idx($old, $default_key, $default_value);
|
|
|
|
$new_value = idx($new, $default_key, $default_value);
|
|
|
|
|
|
|
|
$old_default = ($old_value === $default_value);
|
|
|
|
$new_default = ($new_value === $default_value);
|
|
|
|
|
|
|
|
if ($old_default && $new_default) {
|
|
|
|
unset($old[$default_key]);
|
|
|
|
unset($new[$default_key]);
|
|
|
|
}
|
2014-08-13 14:41:06 -07:00
|
|
|
}
|
|
|
|
|
2016-06-06 19:58:39 +00:00
|
|
|
$metadata = $changeset->getMetadata();
|
|
|
|
|
2014-08-13 14:41:06 -07:00
|
|
|
if ($this->hasOldFile()) {
|
|
|
|
$file = $this->getOldFile();
|
|
|
|
if ($file->getImageWidth()) {
|
|
|
|
$dimensions = $file->getImageWidth().'x'.$file->getImageHeight();
|
|
|
|
$old['file:dimensions'] = $dimensions;
|
|
|
|
}
|
|
|
|
$old['file:mimetype'] = $file->getMimeType();
|
|
|
|
$old['file:size'] = phutil_format_bytes($file->getByteSize());
|
2016-06-06 19:58:39 +00:00
|
|
|
} else {
|
|
|
|
$old['file:mimetype'] = idx($metadata, 'old:file:mime-type');
|
|
|
|
$size = idx($metadata, 'old:file:size');
|
|
|
|
if ($size !== null) {
|
|
|
|
$old['file:size'] = phutil_format_bytes($size);
|
|
|
|
}
|
2014-08-13 14:41:06 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->hasNewFile()) {
|
|
|
|
$file = $this->getNewFile();
|
|
|
|
if ($file->getImageWidth()) {
|
|
|
|
$dimensions = $file->getImageWidth().'x'.$file->getImageHeight();
|
|
|
|
$new['file:dimensions'] = $dimensions;
|
|
|
|
}
|
|
|
|
$new['file:mimetype'] = $file->getMimeType();
|
|
|
|
$new['file:size'] = phutil_format_bytes($file->getByteSize());
|
2016-06-06 19:58:39 +00:00
|
|
|
} else {
|
|
|
|
$new['file:mimetype'] = idx($metadata, 'new:file:mime-type');
|
|
|
|
$size = idx($metadata, 'new:file:size');
|
|
|
|
if ($size !== null) {
|
|
|
|
$new['file:size'] = phutil_format_bytes($size);
|
|
|
|
}
|
2014-08-13 14:41:06 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
return array($old, $new);
|
|
|
|
}
|
|
|
|
|
2015-03-08 15:27:16 -07:00
|
|
|
public function renderUndoTemplates() {
|
|
|
|
$views = array(
|
|
|
|
'l' => id(new PHUIDiffInlineCommentUndoView())->setIsOnRight(false),
|
|
|
|
'r' => id(new PHUIDiffInlineCommentUndoView())->setIsOnRight(true),
|
|
|
|
);
|
|
|
|
|
|
|
|
foreach ($views as $key => $view) {
|
|
|
|
$scaffold = $this->getRowScaffoldForInline($view);
|
|
|
|
$views[$key] = id(new PHUIDiffInlineCommentTableScaffold())
|
|
|
|
->addRowScaffold($scaffold);
|
|
|
|
}
|
|
|
|
|
|
|
|
return $views;
|
|
|
|
}
|
|
|
|
|
2019-02-14 09:54:55 -08:00
|
|
|
final protected function getScopeEngine() {
|
2019-02-20 05:06:42 -08:00
|
|
|
if ($this->scopeEngine === false) {
|
|
|
|
$hunk_starts = $this->getHunkStartLines();
|
|
|
|
|
|
|
|
// If this change is missing context, don't try to identify scopes, since
|
|
|
|
// we won't really be able to get anywhere.
|
|
|
|
$has_multiple_hunks = (count($hunk_starts) > 1);
|
2019-04-01 10:38:25 -07:00
|
|
|
|
|
|
|
$has_offset_hunks = false;
|
|
|
|
if ($hunk_starts) {
|
|
|
|
$has_offset_hunks = (head_key($hunk_starts) != 1);
|
|
|
|
}
|
|
|
|
|
2019-02-20 05:06:42 -08:00
|
|
|
$missing_context = ($has_multiple_hunks || $has_offset_hunks);
|
2019-02-14 09:54:55 -08:00
|
|
|
|
2019-02-20 05:06:42 -08:00
|
|
|
if ($missing_context) {
|
|
|
|
$scope_engine = null;
|
|
|
|
} else {
|
|
|
|
$line_map = $this->getNewLineTextMap();
|
|
|
|
$scope_engine = id(new PhabricatorDiffScopeEngine())
|
|
|
|
->setLineTextMap($line_map);
|
|
|
|
}
|
2019-02-14 09:54:55 -08:00
|
|
|
|
|
|
|
$this->scopeEngine = $scope_engine;
|
|
|
|
}
|
|
|
|
|
|
|
|
return $this->scopeEngine;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function getNewLineTextMap() {
|
|
|
|
$new = $this->getNewLines();
|
|
|
|
|
|
|
|
$text_map = array();
|
|
|
|
foreach ($new as $new_line) {
|
|
|
|
if (!isset($new_line['line'])) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
$text_map[$new_line['line']] = $new_line['text'];
|
|
|
|
}
|
|
|
|
|
|
|
|
return $text_map;
|
|
|
|
}
|
|
|
|
|
2012-12-07 16:19:57 -08:00
|
|
|
}
|