1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-17 04:12:40 +01:00
phorge-phorge/src/applications/differential/render/DifferentialChangesetRenderer.php

668 lines
18 KiB
PHP
Raw Normal View History

<?php
abstract class DifferentialChangesetRenderer {
private $user;
private $changeset;
private $renderingReference;
private $renderPropertyChangeHeader;
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 21:07:46 +02:00
private $isUndershield;
private $hunkStartLines;
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;
private $gaps;
private $mask;
private $depths;
private $originalCharacterEncoding;
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-10 02:41:47 +01:00
private $canMarkDone;
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 21:07:46 +02:00
private $highlightingDisabled;
private $oldFile = false;
private $newFile = false;
abstract public function getRendererKey();
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 21:07:46 +02: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 21:07:46 +02:00
public function setHighlightingDisabled($highlighting_disabled) {
$this->highlightingDisabled = $highlighting_disabled;
return $this;
}
public function getHighlightingDisabled() {
return $this->highlightingDisabled;
}
public function setOriginalCharacterEncoding($original_character_encoding) {
$this->originalCharacterEncoding = $original_character_encoding;
return $this;
}
public function getOriginalCharacterEncoding() {
return $this->originalCharacterEncoding;
}
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 21:07:46 +02:00
public function setIsUndershield($is_undershield) {
$this->isUndershield = $is_undershield;
return $this;
}
public function getIsUndershield() {
return $this->isUndershield;
}
public function setDepths($depths) {
$this->depths = $depths;
return $this;
}
protected function getDepths() {
return $this->depths;
}
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;
}
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;
}
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;
}
public function setNewComments(array $new_comments) {
foreach ($new_comments as $line_number => $comments) {
assert_instances_of($comments, 'PhabricatorInlineCommentInterface');
}
$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) {
assert_instances_of($comments, 'PhabricatorInlineCommentInterface');
}
$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;
}
public function setHunkStartLines(array $hunk_start_lines) {
$this->hunkStartLines = $hunk_start_lines;
return $this;
}
protected function getHunkStartLines() {
return $this->hunkStartLines;
}
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-10 02:41:47 +01:00
private function shouldRenderPropertyChangeHeader() {
return $this->renderPropertyChangeHeader;
}
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-10 02:41:47 +01: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-10 02:41:47 +01:00
public function setCanMarkDone($can_mark_done) {
$this->canMarkDone = $can_mark_done;
return $this;
}
public function getCanMarkDone() {
return $this->canMarkDone;
}
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 23:20:06 +01:00
final public function renderChangesetTable($content) {
$props = null;
if ($this->shouldRenderPropertyChangeHeader()) {
$props = $this->renderPropertyChangeHeader();
}
$notice = null;
if ($this->getIsTopLevel()) {
$force = (!$content && !$props);
$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 23:20:06 +01: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 21:07:46 +02:00
$undershield = null;
if ($this->getIsUndershield()) {
$undershield = $this->renderUndershieldHeader();
}
$result = $notice.$props.$undershield.$content;
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 23:20:06 +01:00
// TODO: Let the user customize their tab width / display style.
// TODO: We should possibly post-process "\r" as well.
// TODO: Both these steps should happen earlier.
$result = str_replace("\t", ' ', $result);
return phutil_safe_html($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 23:20:06 +01:00
}
abstract public function isOneUpRenderer();
abstract public function renderTextChange(
$range_start,
$range_len,
$rows);
abstract public function renderFileChange(
$old = null,
$new = null,
$id = 0,
$vs = 0);
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 23:20:06 +01: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 21:07:46 +02: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 23:20:06 +01:00
protected function didRenderChangesetTableContents($contents) {
return $contents;
}
/**
* 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.
* - `"whitespace"`: Force the text to be shown, and the diff to be
* rendered with all whitespace shown. This is probably only relevant
* when a file is changed only by altering whitespace.
* - `"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.
*/
abstract public function renderShield($message, $force = 'default');
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 23:20:06 +01:00
abstract protected function renderPropertyChangeHeader();
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 23:20:06 +01:00
protected function buildPrimitives($range_start, $range_len) {
$primitives = array();
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 23:20:06 +01:00
$hunk_starts = $this->getHunkStartLines();
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 23:20:06 +01:00
$mask = $this->getMask();
$gaps = $this->getGaps();
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 23:20:06 +01:00
$old = $this->getOldLines();
$new = $this->getNewLines();
$old_render = $this->getOldRender();
$new_render = $this->getNewRender();
$old_comments = $this->getOldComments();
$new_comments = $this->getNewComments();
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 23:20:06 +01: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,
);
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 23:20:06 +01:00
$ii += ($len - 1);
continue;
}
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 23:20:06 +01:00
$ospec = array(
'type' => 'old',
'htype' => null,
'cursor' => $ii,
'line' => null,
'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 23:20:06 +01:00
'render' => null,
);
$nspec = array(
'type' => 'new',
'htype' => null,
'cursor' => $ii,
'line' => null,
'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 23:20:06 +01:00
'render' => null,
'copy' => null,
'coverage' => null,
);
if (isset($old[$ii])) {
$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 23:20:06 +01:00
$ospec['htype'] = $old[$ii]['type'];
if (isset($old_render[$ii])) {
$ospec['render'] = $old_render[$ii];
}
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 23:20:06 +01: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 23:20:06 +01:00
if (isset($new[$ii])) {
$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 23:20:06 +01:00
$nspec['htype'] = $new[$ii]['type'];
if (isset($new_render[$ii])) {
$nspec['render'] = $new_render[$ii];
}
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 23:20:06 +01: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 23:20:06 +01:00
if (isset($hunk_starts[$ospec['line']])) {
$primitives[] = array(
'type' => 'no-context',
);
}
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 23:20:06 +01: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,
);
}
}
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 23:20:06 +01:00
if ($nspec['line'] !== null && isset($new_comments[$nspec['line']])) {
foreach ($new_comments[$nspec['line']] as $comment) {
$primitives[] = array(
'type' => 'inline',
'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 23:20:06 +01:00
'right' => true,
);
}
}
if ($hunk_starts && ($ii == $size - 1)) {
$primitives[] = array(
'type' => 'no-context',
);
}
}
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 23:20:06 +01:00
if ($this->isOneUpRenderer()) {
$primitives = $this->processPrimitivesForOneUp($primitives);
}
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 23:20:06 +01: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'];
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 23:20:06 +01: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;
}
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.
// First, we need to flush the line buffers if they're not empty.
if ($old_buf) {
$out[] = $old_buf;
$old_buf = array();
}
if ($new_buf) {
$out[] = $new_buf;
$new_buf = array();
}
$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 23:20:06 +01: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') {
// If this inline is on the left side, put it after the old lines.
if (!$primitive['right']) {
$out[] = $old_buf;
$out[] = array($primitive);
$old_buf = array();
} else {
$out[] = $old_buf;
$out[] = $new_buf;
$out[] = array($primitive);
$old_buf = array();
$new_buf = array();
}
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 23:20:06 +01:00
} else {
throw new Exception("Unknown primitive type '{$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 23:20:06 +01:00
$out[] = $old_buf;
$out[] = $new_buf;
$out = array_mergev($out);
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 23:20:06 +01:00
return $out;
}
protected function getChangesetProperties($changeset) {
$old = $changeset->getOldProperties();
$new = $changeset->getNewProperties();
// When adding files, don't show the uninteresting 644 filemode change.
if ($changeset->getChangeType() == DifferentialChangeType::TYPE_ADD &&
$new == array('unix:filemode' => '100644')) {
unset($new['unix:filemode']);
}
// Likewise when removing files.
if ($changeset->getChangeType() == DifferentialChangeType::TYPE_DELETE &&
$old == array('unix:filemode' => '100644')) {
unset($old['unix:filemode']);
}
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());
}
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());
}
return array($old, $new);
}
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;
}
}