tornadocontrib/git-arr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
master
git-arr/views/branch.html

51 lines
1.3 KiB
HTML
Raw Permalink Normal View History

views: Improve display on mobile browsers This patch moves the pages to HTML5, and adds some simple meta tags and CSS media constraints so things render better on mobile browsers, while leaving the desktop unaffected. It's still not ideal, though. Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-11-18 02:05:13 +02:00
<!DOCTYPE html>
<html>
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
<head>
views: fix broken URLs involving hierarchical branch names Git branch names can be hierarchical (for example, "wip/parser/fix"), however, git-arr does not take this into account when formulating URLs on branch, tree, and blobs pages. These URLs are dysfunctional because it is assumed incorrectly that a single "../" is sufficient to climb over the branch name when computing relative paths to resources higher in the hierarchy. This problem manifests as failure to load static resources (stylesheet, etc.), broken links to commits on branch pages, and malfunctioning breadcrumb trails. Fix this problem by computing the the proper number of "../" based upon the branch name, rather than assuming that a single "../" will work unconditionally. (This is analogous to the treatment already given to hierarchical pathnames in tree and blob views.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2014-12-31 11:50:08 +02:00
branch: pass branch name view explicitly Passing the branch name into the view indirectly via Repo.new_in_branch() increases cognitive burden, thus outweighing whatever minor convenience (if any) is gained by doing so. The code is easier to reason about when the branch name is passed to the view directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-14 09:46:34 +02:00
% relroot = '../' * (len(branch.split('/')) - 1)
views: fix broken URLs involving hierarchical branch names Git branch names can be hierarchical (for example, "wip/parser/fix"), however, git-arr does not take this into account when formulating URLs on branch, tree, and blobs pages. These URLs are dysfunctional because it is assumed incorrectly that a single "../" is sufficient to climb over the branch name when computing relative paths to resources higher in the hierarchy. This problem manifests as failure to load static resources (stylesheet, etc.), broken links to commits on branch pages, and malfunctioning breadcrumb trails. Fix this problem by computing the the proper number of "../" based upon the branch name, rather than assuming that a single "../" will work unconditionally. (This is analogous to the treatment already given to hierarchical pathnames in tree and blob views.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2014-12-31 11:50:08 +02:00
branch: pass branch name view explicitly Passing the branch name into the view indirectly via Repo.new_in_branch() increases cognitive burden, thus outweighing whatever minor convenience (if any) is gained by doing so. The code is easier to reason about when the branch name is passed to the view directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-14 09:46:34 +02:00
<title>git &raquo; {{repo.name}} &raquo; {{branch}}</title>
views: fix broken URLs involving hierarchical branch names Git branch names can be hierarchical (for example, "wip/parser/fix"), however, git-arr does not take this into account when formulating URLs on branch, tree, and blobs pages. These URLs are dysfunctional because it is assumed incorrectly that a single "../" is sufficient to climb over the branch name when computing relative paths to resources higher in the hierarchy. This problem manifests as failure to load static resources (stylesheet, etc.), broken links to commits on branch pages, and malfunctioning breadcrumb trails. Fix this problem by computing the the proper number of "../" based upon the branch name, rather than assuming that a single "../" will work unconditionally. (This is analogous to the treatment already given to hierarchical pathnames in tree and blob views.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2014-12-31 11:50:08 +02:00
<link rel="stylesheet" type="text/css" href="{{relroot}}../../../../static/git-arr.css"/>
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
views: Improve display on mobile browsers This patch moves the pages to HTML5, and adds some simple meta tags and CSS media constraints so things render better on mobile browsers, while leaving the desktop unaffected. It's still not ideal, though. Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-11-18 02:05:13 +02:00
<meta name=viewport content="width=device-width, initial-scale=1">
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
</head>
<body class="branch">
views: fix broken URLs involving hierarchical branch names Git branch names can be hierarchical (for example, "wip/parser/fix"), however, git-arr does not take this into account when formulating URLs on branch, tree, and blobs pages. These URLs are dysfunctional because it is assumed incorrectly that a single "../" is sufficient to climb over the branch name when computing relative paths to resources higher in the hierarchy. This problem manifests as failure to load static resources (stylesheet, etc.), broken links to commits on branch pages, and malfunctioning breadcrumb trails. Fix this problem by computing the the proper number of "../" based upon the branch name, rather than assuming that a single "../" will work unconditionally. (This is analogous to the treatment already given to hierarchical pathnames in tree and blob views.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2014-12-31 11:50:08 +02:00
<h1><a href="{{relroot}}../../../../">git</a> &raquo;
<a href="{{relroot}}../../">{{repo.name}}</a> &raquo;
branch: pass branch name view explicitly Passing the branch name into the view indirectly via Repo.new_in_branch() increases cognitive burden, thus outweighing whatever minor convenience (if any) is gained by doing so. The code is easier to reason about when the branch name is passed to the view directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-14 09:46:34 +02:00
<a href="./">{{branch}}</a>
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
</h1>
<p>
<a class="explicit" href="t/">Browse current source tree</a>
</p>
branch: pass branch name view explicitly Passing the branch name into the view indirectly via Repo.new_in_branch() increases cognitive burden, thus outweighing whatever minor convenience (if any) is gained by doing so. The code is easier to reason about when the branch name is passed to the view directly. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-14 09:46:34 +02:00
% commits = repo.commits("refs/heads/" + branch,
views: branch/paginate: fix incorrectly enabled "next" link When the number of commits on a branch page is less than 'commits_per_page', the pagination "next" link is disabled, indicating correctly that this is the final page. However, if the number of commits on the branch page is exactly 'commits_per_page', then the "next" link is incorrectly enabled, even on the final page. When clicked, the user is taken to a "404 Page not found" error page, which makes for a poor user experience. Fix this problem by reliably detecting when the branch page is the final one. Do so by asking for (but not displaying) one commit more than actually needed by the page. If the additional commit is successfully retrieved, then another page definitely follows this one. If not retrieved, then this is definitely the final page. (Unfortunately, the seemingly more expedient approach of checking if the final commit on the current page is a root commit -- has no parents -- is not a reliable indicator that this the final page since a branch may have multiple root commits due to merging.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-01 23:41:08 +02:00
% limit = repo.info.commits_per_page + 1,
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% offset = repo.info.commits_per_page * offset)
% commits = list(commits)
% if len(commits) == 0:
% abort(404, "No more commits")
% end
views: branch/paginate: fix incorrectly enabled "next" link When the number of commits on a branch page is less than 'commits_per_page', the pagination "next" link is disabled, indicating correctly that this is the final page. However, if the number of commits on the branch page is exactly 'commits_per_page', then the "next" link is incorrectly enabled, even on the final page. When clicked, the user is taken to a "404 Page not found" error page, which makes for a poor user experience. Fix this problem by reliably detecting when the branch page is the final one. Do so by asking for (but not displaying) one commit more than actually needed by the page. If the additional commit is successfully retrieved, then another page definitely follows this one. If not retrieved, then this is definitely the final page. (Unfortunately, the seemingly more expedient approach of checking if the final commit on the current page is a root commit -- has no parents -- is not a reliable indicator that this the final page since a branch may have multiple root commits due to merging.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-01 23:41:08 +02:00
% more = len(commits) > repo.info.commits_per_page
% if more:
% commits = commits[:-1]
% end
views: branch/paginate: teach "next" link to respect 'max_pages' Pagination link "next" does not respect 'max_pages', thus it incorrectly remains enabled on the final page capped by 'max_pages'. When clicked, the user is taken to a "404 Page not found" error page, which makes for a poor user experience. Fix this problem by teaching the "next" link to respect 'max_pages'. (As a side-effect, this also causes 'serve' mode to respect 'max_pages', which was not previously the case. This change of behavior is appropriate since it brings 'serve' mode, which is intended primarily for testing, more in line with 'generate' mode.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-01 23:41:09 +02:00
% more = more and offset + 1 < repo.info.max_pages
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
views: branch/paginate: fix incorrectly enabled "next" link When the number of commits on a branch page is less than 'commits_per_page', the pagination "next" link is disabled, indicating correctly that this is the final page. However, if the number of commits on the branch page is exactly 'commits_per_page', then the "next" link is incorrectly enabled, even on the final page. When clicked, the user is taken to a "404 Page not found" error page, which makes for a poor user experience. Fix this problem by reliably detecting when the branch page is the final one. Do so by asking for (but not displaying) one commit more than actually needed by the page. If the additional commit is successfully retrieved, then another page definitely follows this one. If not retrieved, then this is definitely the final page. (Unfortunately, the seemingly more expedient approach of checking if the final commit on the current page is a root commit -- has no parents -- is not a reliable indicator that this the final page since a branch may have multiple root commits due to merging.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-01 23:41:08 +02:00
% include paginate more = more, offset = offset
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% kwargs = dict(repo=repo, commits=commits,
views: fix broken URLs involving hierarchical branch names Git branch names can be hierarchical (for example, "wip/parser/fix"), however, git-arr does not take this into account when formulating URLs on branch, tree, and blobs pages. These URLs are dysfunctional because it is assumed incorrectly that a single "../" is sufficient to climb over the branch name when computing relative paths to resources higher in the hierarchy. This problem manifests as failure to load static resources (stylesheet, etc.), broken links to commits on branch pages, and malfunctioning breadcrumb trails. Fix this problem by computing the the proper number of "../" based upon the branch name, rather than assuming that a single "../" will work unconditionally. (This is analogous to the treatment already given to hierarchical pathnames in tree and blob views.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2014-12-31 11:50:08 +02:00
% shorten=shorten, repo_root=relroot + "../..")
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
% include commit-list **kwargs
<p/>
views: branch/paginate: fix incorrectly enabled "next" link When the number of commits on a branch page is less than 'commits_per_page', the pagination "next" link is disabled, indicating correctly that this is the final page. However, if the number of commits on the branch page is exactly 'commits_per_page', then the "next" link is incorrectly enabled, even on the final page. When clicked, the user is taken to a "404 Page not found" error page, which makes for a poor user experience. Fix this problem by reliably detecting when the branch page is the final one. Do so by asking for (but not displaying) one commit more than actually needed by the page. If the additional commit is successfully retrieved, then another page definitely follows this one. If not retrieved, then this is definitely the final page. (Unfortunately, the seemingly more expedient approach of checking if the final commit on the current page is a root commit -- has no parents -- is not a reliable indicator that this the final page since a branch may have multiple root commits due to merging.) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2015-01-01 23:41:08 +02:00
% include paginate more = more, offset = offset
Initial commit Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar>
2012-09-16 13:17:56 +03:00
</body>
</html>
Reference in New Issue Copy Permalink