All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] gitweb: Refactor project list routines
@ 2009-11-06 15:10   ` Petr Baudis
  2009-11-06 15:22     ` Petr Baudis
  2009-11-06 18:56     ` J.H.
  0 siblings, 2 replies; 8+ messages in thread
From: Petr Baudis @ 2009-11-06 15:10 UTC (permalink / raw)
  To: git; +Cc: Petr Baudis

This is a preparatory patch for separation of project list and frontpage
actions; it factors out most logic of git_project_list():

	* git_project_list_all() as a git_project_list_body() wrapper for
	  complete project listing
	* git_project_search_form() for printing the project search form

Also, git_project_list_ctags() is now separated out of
git_project_list_body(), showing tag cloud for given project list.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 gitweb/gitweb.perl |   69 +++++++++++++++++++++++++++++++---------------------
 1 files changed, 41 insertions(+), 28 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e4cbfc3..e82ca45 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4201,10 +4201,9 @@ sub git_patchset_body {
 # project in the list, removing invalid projects from returned list
 # NOTE: modifies $projlist, but does not remove entries from it
 sub fill_project_list_info {
-	my ($projlist, $check_forks) = @_;
+	my ($projlist, $check_forks, $show_ctags) = @_;
 	my @projects;
 
-	my $show_ctags = gitweb_check_feature('ctags');
  PROJECT:
 	foreach my $pr (@$projlist) {
 		my (@activity) = git_get_last_activity($pr->{'path'});
@@ -4254,12 +4253,26 @@ sub print_sort_th {
 	}
 }
 
+sub git_project_list_ctags {
+	my ($projects) = @_;
+
+	my %ctags;
+	foreach my $p (@$projects) {
+		foreach my $ct (keys %{$p->{'ctags'}}) {
+			$ctags{$ct} += $p->{'ctags'}->{$ct};
+		}
+	}
+	my $cloud = git_populate_project_tagcloud(\%ctags);
+	print git_show_project_tagcloud($cloud, 64);
+}
+
 sub git_project_list_body {
 	# actually uses global variable $project
 	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
 
 	my $check_forks = gitweb_check_feature('forks');
-	my @projects = fill_project_list_info($projlist, $check_forks);
+	my $show_ctags = gitweb_check_feature('ctags');
+	my @projects = fill_project_list_info($projlist, $check_forks, $show_ctags);
 
 	$order ||= $default_projects_order;
 	$from = 0 unless defined $from;
@@ -4278,16 +4291,8 @@ sub git_project_list_body {
 		@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
 	}
 
-	my $show_ctags = gitweb_check_feature('ctags');
 	if ($show_ctags) {
-		my %ctags;
-		foreach my $p (@projects) {
-			foreach my $ct (keys %{$p->{'ctags'}}) {
-				$ctags{$ct} += $p->{'ctags'}->{$ct};
-			}
-		}
-		my $cloud = git_populate_project_tagcloud(\%ctags);
-		print git_show_project_tagcloud($cloud, 64);
+		git_project_list_ctags(\@projects);
 	}
 
 	print "<table class=\"project_list\">\n";
@@ -4361,6 +4366,28 @@ sub git_project_list_body {
 	print "</table>\n";
 }
 
+sub git_project_search_form {
+	print $cgi->startform(-method => "get") .
+	      "<p class=\"projsearch\">Search:\n" .
+	      $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
+	      "</p>" .
+	      $cgi->end_form() . "\n";
+}
+
+sub git_project_list_all {
+	my $order = $input_params{'order'};
+	if (defined $order && $order !~ m/none|project|descr|owner|age/) {
+		die_error(400, "Unknown order parameter");
+	}
+
+	my @list = git_get_projects_list();
+	if (!@list) {
+		die_error(404, "No projects found");
+	}
+
+	git_project_list_body(\@list, $order);
+}
+
 sub git_shortlog_body {
 	# uses global variable $project
 	my ($commitlist, $from, $to, $refs, $extra) = @_;
@@ -4630,28 +4657,14 @@ sub git_search_grep_body {
 ## actions
 
 sub git_project_list {
-	my $order = $input_params{'order'};
-	if (defined $order && $order !~ m/none|project|descr|owner|age/) {
-		die_error(400, "Unknown order parameter");
-	}
-
-	my @list = git_get_projects_list();
-	if (!@list) {
-		die_error(404, "No projects found");
-	}
-
 	git_header_html();
 	if (-f $home_text) {
 		print "<div class=\"index_include\">\n";
 		insert_file($home_text);
 		print "</div>\n";
 	}
-	print $cgi->startform(-method => "get") .
-	      "<p class=\"projsearch\">Search:\n" .
-	      $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
-	      "</p>" .
-	      $cgi->end_form() . "\n";
-	git_project_list_body(\@list, $order);
+	git_project_search_form();
+	git_project_list_all();
 	git_footer_html();
 }
 
-- 
tg: (8cc62c1..) t/frontpage/refactor (depends on: vanilla/master)

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH] gitweb: Polish the content tags support
@ 2009-11-06 15:10 Petr Baudis
  2009-11-06 15:11 ` [PATCH] gitweb: Support for no project list on gitweb front page Petr Baudis
  0 siblings, 1 reply; 8+ messages in thread
From: Petr Baudis @ 2009-11-06 15:10 UTC (permalink / raw)
  To: git; +Cc: Petr Baudis

This patch integrates the tag filtering CGI parameter into the framework
for parameter passing, dropping 'by_tag' and instead using query name 't'
and symbolic name 'ctag_filter'. Compatibility support for 'by_tag' query
name is retained.

This means that content tag links are now created using $cgi->a() and
the href() method, and that they now point to the proper action;
project_list in case of global content tags, forks in case of per-fork
content tags. Also any other arguments like sorting order of projects
are replayed within the links.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 gitweb/gitweb.perl |   37 +++++++++++++++++++++++--------------
 1 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e82ca45..97e88b4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -566,6 +566,7 @@ our @cgi_param_mapping = (
 	searchtext => "s",
 	searchtype => "st",
 	snapshot_format => "sf",
+	ctag_filter => 't',
 	extra_options => "opt",
 	search_use_regexp => "sr",
 );
@@ -622,6 +623,11 @@ while (my ($name, $symbol) = each %cgi_param_mapping) {
 	}
 }
 
+# Backwards compatibility - by_tag= <=> t=
+if ($cgi->param('by_tag')) {
+	$input_params{'ctag_filter'} = $cgi->param('by_tag');
+}
+
 # now read PATH_INFO and update the parameter list for missing parameters
 sub evaluate_path_info {
 	return if defined $input_params{'project'};
@@ -2257,7 +2263,7 @@ sub git_get_project_ctags {
 }
 
 sub git_populate_project_tagcloud {
-	my $ctags = shift;
+	my ($ctags, $action) = @_;
 
 	# First, merge different-cased tags; tags vote on casing
 	my %ctags_lc;
@@ -2280,7 +2286,8 @@ sub git_populate_project_tagcloud {
 			$title =~ s/ /&nbsp;/g;
 			$title =~ s/^/&nbsp;/g;
 			$title =~ s/$/&nbsp;/g;
-			$cloud->add($title, $home_link."?by_tag=".$_, $ctags_lc{$_}->{count});
+			$cloud->add($title, href(-replay=>1, action=>$action, ctag_filter=>$_),
+			            $ctags_lc{$_}->{count});
 		}
 	} else {
 		$cloud = \%ctags_lc;
@@ -2289,14 +2296,15 @@ sub git_populate_project_tagcloud {
 }
 
 sub git_show_project_tagcloud {
-	my ($cloud, $count) = @_;
+	my ($cloud, $count, $action) = @_;
 	print STDERR ref($cloud)."..\n";
 	if (ref $cloud eq 'HTML::TagCloud') {
 		return $cloud->html_and_css($count);
 	} else {
 		my @tags = sort { $cloud->{$a}->{count} <=> $cloud->{$b}->{count} } keys %$cloud;
 		return '<p align="center">' . join (', ', map {
-			"<a href=\"$home_link?by_tag=$_\">$cloud->{$_}->{topname}</a>"
+			$cgi->a({-href => href(-replay=>1, action=>$action, ctag_filter=>$_)},
+				$cloud->{$_}->{topname});
 		} splice(@tags, 0, $count)) . '</p>';
 	}
 }
@@ -4254,7 +4262,8 @@ sub print_sort_th {
 }
 
 sub git_project_list_ctags {
-	my ($projects) = @_;
+	my ($projects, $action) = @_;
+	$action ||= 'project_list';
 
 	my %ctags;
 	foreach my $p (@$projects) {
@@ -4262,13 +4271,13 @@ sub git_project_list_ctags {
 			$ctags{$ct} += $p->{'ctags'}->{$ct};
 		}
 	}
-	my $cloud = git_populate_project_tagcloud(\%ctags);
-	print git_show_project_tagcloud($cloud, 64);
+	my $cloud = git_populate_project_tagcloud(\%ctags, $action);
+	print git_show_project_tagcloud($cloud, 64, $action);
 }
 
 sub git_project_list_body {
 	# actually uses global variable $project
-	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
+	my ($projlist, $order, $from, $to, $extra, $no_header, $ctags_action) = @_;
 
 	my $check_forks = gitweb_check_feature('forks');
 	my $show_ctags = gitweb_check_feature('ctags');
@@ -4292,7 +4301,7 @@ sub git_project_list_body {
 	}
 
 	if ($show_ctags) {
-		git_project_list_ctags(\@projects);
+		git_project_list_ctags(\@projects, $ctags_action);
 	}
 
 	print "<table class=\"project_list\">\n";
@@ -4309,7 +4318,7 @@ sub git_project_list_body {
 		      "</tr>\n";
 	}
 	my $alternate = 1;
-	my $tagfilter = $cgi->param('by_tag');
+	my $tagfilter = $input_params{'ctag_filter'};
 	for (my $i = $from; $i <= $to; $i++) {
 		my $pr = $projects[$i];
 
@@ -4682,7 +4691,7 @@ sub git_forks {
 	git_header_html();
 	git_print_page_nav('','');
 	git_print_header_div('summary', "$project forks");
-	git_project_list_body(\@list, $order);
+	git_project_list_body(\@list, $order, undef, undef, undef, undef, 'forks');
 	git_footer_html();
 }
 
@@ -4756,12 +4765,12 @@ sub git_summary {
 	my $show_ctags = gitweb_check_feature('ctags');
 	if ($show_ctags) {
 		my $ctags = git_get_project_ctags($project);
-		my $cloud = git_populate_project_tagcloud($ctags);
+		my $cloud = git_populate_project_tagcloud($ctags, 'project_list');
 		print "<tr id=\"metadata_ctags\"><td>Content tags:<br />";
 		print "</td>\n<td>" unless %$ctags;
 		print "<form action=\"$show_ctags\" method=\"post\"><input type=\"hidden\" name=\"p\" value=\"$project\" />Add: <input type=\"text\" name=\"t\" size=\"8\" /></form>";
 		print "</td>\n<td>" if %$ctags;
-		print git_show_project_tagcloud($cloud, 48);
+		print git_show_project_tagcloud($cloud, 48, 'project_list');
 		print "</td></tr>";
 	}
 
@@ -4805,7 +4814,7 @@ sub git_summary {
 		git_project_list_body(\@forklist, 'age', 0, 15,
 		                      $#forklist <= 15 ? undef :
 		                      $cgi->a({-href => href(action=>"forks")}, "..."),
-		                      'no_header');
+		                      'no_header', 'forks');
 	}
 
 	git_footer_html();
-- 
tg: (73bafe5..) t/frontpage/ctags (depends on: t/frontpage/refactor)

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* [PATCH] gitweb: Support for no project list on gitweb front page
@ 2009-11-06 15:11 ` Petr Baudis
  2009-11-06 15:10   ` [PATCH] gitweb: Refactor project list routines Petr Baudis
  2009-11-06 19:03   ` [PATCH] gitweb: Support for no project list on gitweb front page J.H.
  0 siblings, 2 replies; 8+ messages in thread
From: Petr Baudis @ 2009-11-06 15:11 UTC (permalink / raw)
  To: git; +Cc: Petr Baudis

On very large sites like repo.or.cz (but maybe also git.debian.org,
git.kernel.org, etc.), it is desirable not to have the project list
on the front page since generating it is significant overhead and it
takes significant data transfer and load time for the user, who might
prefer to instead use the search form and possibly content tags to
navigate to the target project. A link to the full list of projects is
still available on the front page for users who wish to browse it. The
whole feature is turned off by default.

The patch introduces a new config variable $frontpage_no_project_list,
by default 0 keeping the current behavior; if set to 1, no project list
will be shown, but all projects will be still scanned if ctags are
enabled; if set to 2, no project will be shown and no projects will
be scanned while showing the front page. The compromise value of 1 is
useful for sites where project scan time is not an issue or which
use additional project list caching patches.

The patch furthermore modifies project_list action not to show the
index text, and introduces new default action frontpage which is by
default identical to old project_list action, but can be further
controlled by the $frontpage_no_project_list variable.

Signed-off-by: Petr Baudis <pasky@suse.cz>

---
 gitweb/README      |    8 ++++++++
 gitweb/gitweb.css  |    5 +++++
 gitweb/gitweb.perl |   32 +++++++++++++++++++++++++++++---
 3 files changed, 42 insertions(+), 3 deletions(-)

diff --git a/gitweb/README b/gitweb/README
index 66c6a93..c5fd1b8 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -223,6 +223,14 @@ not include variables usually directly set during build):
    repositories from launching cross-site scripting (XSS) attacks.  Set this
    to true if you don't trust the content of your repositories. The default
    is false.
+ * $frontpage_no_project_list
+   If 0, the gitweb frontpage will contain the project list; if 1 instead,
+   it will contain just the index text, search form, tag cloud (if enabled)
+   and a link to the actual project list. The page is reduced, but all
+   projects still need to be scanned for the tag cloud construction. If the
+   option is set to 2, not even the tag cloud will be shown; this is fastest.
+   This option is useful for sites with large amount of projects. The default
+   is 0.
 
 
 Projects list file format
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index cb3f0ba..9fee3f0 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -97,6 +97,11 @@ div.readme {
 	padding: 8px;
 }
 
+p.projectlist_link {
+	text-align: center;
+	font-weight: bold;
+}
+
 a.title:hover {
 	background-color: #d9d8d1;
 }
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 97e88b4..48326a4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -152,6 +152,11 @@ our @diff_opts = ('-M'); # taken from git_commit
 # the gitweb domain.
 our $prevent_xss = 0;
 
+# Whether to include project list on the gitweb front page; 0 means yes,
+# 1 means no list but show tag cloud if enabled (all projects still need
+# to be scanned), 2 means no list and no tag cloud (very fast)
+our $frontpage_no_project_list = 0;
+
 # information about snapshot formats that gitweb is capable of serving
 our %known_snapshot_formats = (
 	# name => {
@@ -601,6 +606,7 @@ our %actions = (
 	"object" => \&git_object,
 	# those below don't need $project
 	"opml" => \&git_opml,
+	"frontpage" => \&git_frontpage,
 	"project_list" => \&git_project_list,
 	"project_index" => \&git_project_index,
 );
@@ -901,13 +907,13 @@ if (!defined $action) {
 	} elsif (defined $project) {
 		$action = 'summary';
 	} else {
-		$action = 'project_list';
+		$action = 'frontpage';
 	}
 }
 if (!defined($actions{$action})) {
 	die_error(400, "Unknown action");
 }
-if ($action !~ m/^(?:opml|project_list|project_index)$/ &&
+if ($action !~ m/^(?:opml|frontpage|project_list|project_index)$/ &&
     !$project) {
 	die_error(400, "Project needed");
 }
@@ -4377,6 +4383,7 @@ sub git_project_list_body {
 
 sub git_project_search_form {
 	print $cgi->startform(-method => "get") .
+	      $cgi->hidden({-name=>"a", -value=>"project_list"}) . "\n" .
 	      "<p class=\"projsearch\">Search:\n" .
 	      $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
 	      "</p>" .
@@ -4665,7 +4672,7 @@ sub git_search_grep_body {
 ## ======================================================================
 ## actions
 
-sub git_project_list {
+sub git_frontpage {
 	git_header_html();
 	if (-f $home_text) {
 		print "<div class=\"index_include\">\n";
@@ -4673,6 +4680,25 @@ sub git_project_list {
 		print "</div>\n";
 	}
 	git_project_search_form();
+	if (not $frontpage_no_project_list) {
+		git_project_list_all();
+	} else {
+		my $show_ctags = gitweb_check_feature('ctags');
+		if ($frontpage_no_project_list == 1 and $show_ctags) {
+			my @list = git_get_projects_list();
+			my @projects = fill_project_list_info(\@list, gitweb_check_feature('forks'), $show_ctags);
+			git_project_list_ctags(\@projects);
+		}
+		print "<p class=\"projectlist_link\">" .
+			$cgi->a({-href => href(action=>'project_list')}, "Browse all projects") .
+			"</p>\n";
+	}
+	git_footer_html();
+}
+
+sub git_project_list {
+	git_header_html();
+	git_project_search_form();
 	git_project_list_all();
 	git_footer_html();
 }
-- 
tg: (e731dcd..) t/frontpage/separate (depends on: t/frontpage/ctags)

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] gitweb: Refactor project list routines
  2009-11-06 15:10   ` [PATCH] gitweb: Refactor project list routines Petr Baudis
@ 2009-11-06 15:22     ` Petr Baudis
  2009-11-06 18:56     ` J.H.
  1 sibling, 0 replies; 8+ messages in thread
From: Petr Baudis @ 2009-11-06 15:22 UTC (permalink / raw)
  To: git

  Oops, I'm sorry, I expected tg mail to submit the mails in series...
The correct order is:

	[PATCH] gitweb: Refactor project list routines
	[PATCH] gitweb: Support for no project list on gitweb front page
	[PATCH] gitweb: Polish the content tags support

(The blob linenr patch is independent.)

				Petr "Pasky" Baudis

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] gitweb: Refactor project list routines
  2009-11-06 15:10   ` [PATCH] gitweb: Refactor project list routines Petr Baudis
  2009-11-06 15:22     ` Petr Baudis
@ 2009-11-06 18:56     ` J.H.
  2009-11-16 17:56       ` Petr Baudis
  1 sibling, 1 reply; 8+ messages in thread
From: J.H. @ 2009-11-06 18:56 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git

Petr,

After digging into some of the ctags stuff recently looking at it, I 
have some serious concerns over making it a more primary interface 
inside of Gitweb.

1) The mechanism to assign ctags and it's associated documentation is 
cryptic at best.  It took me reverse engineering the code to figure out 
how to add tags to a repository, and even then there are very simple 
means of trivially breaking them (Like put 0 inside of a ctag file, the 
divide by zero errors are kinda concerning for instance).

2) If the repository is cloned the ctag information is not retained, 
which means there is no real way for the original developer to manage or 
move this information between different hosting sites, I.E. repo.or.cz 
and kernel.org (though I'll admit I have it turned off)

So if your going to eliminate the project listing, with the general 
intention of using the tag cloud as more of a primary search mechanism, 
including the search box, I think there's some serious work that needs 
to be put into the ctags system because in it's current state, for the 
likes of kernel.org, it's unusable, unstable and not something I would 
recommend to anyone to run in production.  I like the idea, I just have 
concerns over it's current implementation.

- John 'Warthog9' Hawley

Petr Baudis wrote:
> This is a preparatory patch for separation of project list and frontpage
> actions; it factors out most logic of git_project_list():
> 
> 	* git_project_list_all() as a git_project_list_body() wrapper for
> 	  complete project listing
> 	* git_project_search_form() for printing the project search form
> 
> Also, git_project_list_ctags() is now separated out of
> git_project_list_body(), showing tag cloud for given project list.
> 
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> 
> ---
>  gitweb/gitweb.perl |   69 +++++++++++++++++++++++++++++++---------------------
>  1 files changed, 41 insertions(+), 28 deletions(-)
> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e4cbfc3..e82ca45 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -4201,10 +4201,9 @@ sub git_patchset_body {
>  # project in the list, removing invalid projects from returned list
>  # NOTE: modifies $projlist, but does not remove entries from it
>  sub fill_project_list_info {
> -	my ($projlist, $check_forks) = @_;
> +	my ($projlist, $check_forks, $show_ctags) = @_;
>  	my @projects;
>  
> -	my $show_ctags = gitweb_check_feature('ctags');
>   PROJECT:
>  	foreach my $pr (@$projlist) {
>  		my (@activity) = git_get_last_activity($pr->{'path'});
> @@ -4254,12 +4253,26 @@ sub print_sort_th {
>  	}
>  }
>  
> +sub git_project_list_ctags {
> +	my ($projects) = @_;
> +
> +	my %ctags;
> +	foreach my $p (@$projects) {
> +		foreach my $ct (keys %{$p->{'ctags'}}) {
> +			$ctags{$ct} += $p->{'ctags'}->{$ct};
> +		}
> +	}
> +	my $cloud = git_populate_project_tagcloud(\%ctags);
> +	print git_show_project_tagcloud($cloud, 64);
> +}
> +
>  sub git_project_list_body {
>  	# actually uses global variable $project
>  	my ($projlist, $order, $from, $to, $extra, $no_header) = @_;
>  
>  	my $check_forks = gitweb_check_feature('forks');
> -	my @projects = fill_project_list_info($projlist, $check_forks);
> +	my $show_ctags = gitweb_check_feature('ctags');
> +	my @projects = fill_project_list_info($projlist, $check_forks, $show_ctags);
>  
>  	$order ||= $default_projects_order;
>  	$from = 0 unless defined $from;
> @@ -4278,16 +4291,8 @@ sub git_project_list_body {
>  		@projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @projects;
>  	}
>  
> -	my $show_ctags = gitweb_check_feature('ctags');
>  	if ($show_ctags) {
> -		my %ctags;
> -		foreach my $p (@projects) {
> -			foreach my $ct (keys %{$p->{'ctags'}}) {
> -				$ctags{$ct} += $p->{'ctags'}->{$ct};
> -			}
> -		}
> -		my $cloud = git_populate_project_tagcloud(\%ctags);
> -		print git_show_project_tagcloud($cloud, 64);
> +		git_project_list_ctags(\@projects);
>  	}
>  
>  	print "<table class=\"project_list\">\n";
> @@ -4361,6 +4366,28 @@ sub git_project_list_body {
>  	print "</table>\n";
>  }
>  
> +sub git_project_search_form {
> +	print $cgi->startform(-method => "get") .
> +	      "<p class=\"projsearch\">Search:\n" .
> +	      $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
> +	      "</p>" .
> +	      $cgi->end_form() . "\n";
> +}
> +
> +sub git_project_list_all {
> +	my $order = $input_params{'order'};
> +	if (defined $order && $order !~ m/none|project|descr|owner|age/) {
> +		die_error(400, "Unknown order parameter");
> +	}
> +
> +	my @list = git_get_projects_list();
> +	if (!@list) {
> +		die_error(404, "No projects found");
> +	}
> +
> +	git_project_list_body(\@list, $order);
> +}
> +
>  sub git_shortlog_body {
>  	# uses global variable $project
>  	my ($commitlist, $from, $to, $refs, $extra) = @_;
> @@ -4630,28 +4657,14 @@ sub git_search_grep_body {
>  ## actions
>  
>  sub git_project_list {
> -	my $order = $input_params{'order'};
> -	if (defined $order && $order !~ m/none|project|descr|owner|age/) {
> -		die_error(400, "Unknown order parameter");
> -	}
> -
> -	my @list = git_get_projects_list();
> -	if (!@list) {
> -		die_error(404, "No projects found");
> -	}
> -
>  	git_header_html();
>  	if (-f $home_text) {
>  		print "<div class=\"index_include\">\n";
>  		insert_file($home_text);
>  		print "</div>\n";
>  	}
> -	print $cgi->startform(-method => "get") .
> -	      "<p class=\"projsearch\">Search:\n" .
> -	      $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
> -	      "</p>" .
> -	      $cgi->end_form() . "\n";
> -	git_project_list_body(\@list, $order);
> +	git_project_search_form();
> +	git_project_list_all();
>  	git_footer_html();
>  }
>  

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] gitweb: Support for no project list on gitweb front page
  2009-11-06 15:11 ` [PATCH] gitweb: Support for no project list on gitweb front page Petr Baudis
  2009-11-06 15:10   ` [PATCH] gitweb: Refactor project list routines Petr Baudis
@ 2009-11-06 19:03   ` J.H.
  2009-11-16 17:52     ` Petr Baudis
  1 sibling, 1 reply; 8+ messages in thread
From: J.H. @ 2009-11-06 19:03 UTC (permalink / raw)
  To: Petr Baudis; +Cc: git

Petr Baudis wrote:
> On very large sites like repo.or.cz (but maybe also git.debian.org,
> git.kernel.org, etc.),

I think between our own caching (which I'll be submitting a cleaned up 
patch for here shortly for mainline inclusion) and our users want to 
*NOT* deal with searching or pagination this actually isn't that useful 
to us, despite having a signifigant number of projects, and the front 
page (at leas for us) only weighing in at 567,710bytes means that we are 
moving less data to show the git.kernel.org page than facebook does to 
show their home screen (I.E. anything modern can trivially cope with that)

> it is desirable not to have the project list
> on the front page since generating it is significant overhead and it
> takes significant data transfer and load time for the user, who might
> prefer to instead use the search form and possibly content tags to
> navigate to the target project. A link to the full list of projects is
> still available on the front page for users who wish to browse it. The
> whole feature is turned off by default.
> 
> The patch introduces a new config variable $frontpage_no_project_list,
> by default 0 keeping the current behavior; if set to 1, no project list
> will be shown, but all projects will be still scanned if ctags are
> enabled; if set to 2, no project will be shown and no projects will
> be scanned while showing the front page. The compromise value of 1 is
> useful for sites where project scan time is not an issue or which
> use additional project list caching patches.

I question the need for 0,1,2.  If the site doesn't want something like 
the tag cloud they are already going to turn it off with the normal 
cloud system.  I think this should be either a bitmask or an array to 
explicitly turn particular things on or off, or a binary value that 
would *ONLY* deal with showing the project listing.

- John 'Warthog9' Hawley

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] gitweb: Support for no project list on gitweb front page
  2009-11-06 19:03   ` [PATCH] gitweb: Support for no project list on gitweb front page J.H.
@ 2009-11-16 17:52     ` Petr Baudis
  0 siblings, 0 replies; 8+ messages in thread
From: Petr Baudis @ 2009-11-16 17:52 UTC (permalink / raw)
  To: J.H.; +Cc: git

On Fri, Nov 06, 2009 at 11:03:01AM -0800, J.H. wrote:
> Petr Baudis wrote:
> >On very large sites like repo.or.cz (but maybe also git.debian.org,
> >git.kernel.org, etc.),
> 
> I think between our own caching (which I'll be submitting a cleaned
> up patch for here shortly for mainline inclusion) and our users want
> to *NOT* deal with searching or pagination this actually isn't that
> useful to us, despite having a signifigant number of projects, and
> the front page (at leas for us) only weighing in at 567,710bytes
> means that we are moving less data to show the git.kernel.org page
> than facebook does to show their home screen (I.E. anything modern
> can trivially cope with that)

Sure, you still have much fewer projects than repo.or.cz. :-)
Perhaps others will still find it useful.

> >it is desirable not to have the project list
> >on the front page since generating it is significant overhead and it
> >takes significant data transfer and load time for the user, who might
> >prefer to instead use the search form and possibly content tags to
> >navigate to the target project. A link to the full list of projects is
> >still available on the front page for users who wish to browse it. The
> >whole feature is turned off by default.
> >
> >The patch introduces a new config variable $frontpage_no_project_list,
> >by default 0 keeping the current behavior; if set to 1, no project list
> >will be shown, but all projects will be still scanned if ctags are
> >enabled; if set to 2, no project will be shown and no projects will
> >be scanned while showing the front page. The compromise value of 1 is
> >useful for sites where project scan time is not an issue or which
> >use additional project list caching patches.
> 
> I question the need for 0,1,2.  If the site doesn't want something
> like the tag cloud they are already going to turn it off with the
> normal cloud system.  I think this should be either a bitmask or an
> array to explicitly turn particular things on or off, or a binary
> value that would *ONLY* deal with showing the project listing.

I have no problem with either way, 2 seemed useful so that people can
continue to use ctags but have the front page without any project
scanning whatsoever, but if people think it makes no sense to have it,
I can drop it. I will resend the patch with this being a bitmask
instead, though.

-- 
				Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] gitweb: Refactor project list routines
  2009-11-06 18:56     ` J.H.
@ 2009-11-16 17:56       ` Petr Baudis
  0 siblings, 0 replies; 8+ messages in thread
From: Petr Baudis @ 2009-11-16 17:56 UTC (permalink / raw)
  To: J.H.; +Cc: git

  Hi!

On Fri, Nov 06, 2009 at 10:56:02AM -0800, J.H. wrote:
> 2) If the repository is cloned the ctag information is not retained,
> which means there is no real way for the original developer to
> manage or move this information between different hosting sites,
> I.E. repo.or.cz and kernel.org (though I'll admit I have it turned
> off)

  This is interesting argument, I have always thought about ctags being
a rather site-specific mechanism and I think it would've meet with a lot
of user opposition to e.g. keep ctags in a specific branch; I can think
of no other good way to do it either.

> So if your going to eliminate the project listing, with the general
> intention of using the tag cloud as more of a primary search
> mechanism, including the search box, I think there's some serious
> work that needs to be put into the ctags system because in it's
> current state, for the likes of kernel.org, it's unusable, unstable
> and not something I would recommend to anyone to run in production.
> I like the idea, I just have concerns over it's current
> implementation.

  This patch is orthogonal to that, I believe. I agree that the ctags
mechanism is somewhat hackish; unfortunately, I personally don't have
the time to fix it up properly. I think it is still good enough for
many users, and the frontpage mechanism would be quite useful even for
people who don't want to use content tags.

-- 
				Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2009-11-16 17:56 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-06 15:10 [PATCH] gitweb: Polish the content tags support Petr Baudis
2009-11-06 15:11 ` [PATCH] gitweb: Support for no project list on gitweb front page Petr Baudis
2009-11-06 15:10   ` [PATCH] gitweb: Refactor project list routines Petr Baudis
2009-11-06 15:22     ` Petr Baudis
2009-11-06 18:56     ` J.H.
2009-11-16 17:56       ` Petr Baudis
2009-11-06 19:03   ` [PATCH] gitweb: Support for no project list on gitweb front page J.H.
2009-11-16 17:52     ` Petr Baudis

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.