[PATCH] gitweb: Refactor project list routines

4 messages Options
Embed this post
Permalink
Petr Baudis

[PATCH] gitweb: Refactor project list routines

Reply Threaded More More options
Print post
Permalink
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 <[hidden email]>

---
 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)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Petr Baudis

Re: [PATCH] gitweb: Refactor project list routines

Reply Threaded More More options
Print post
Permalink
  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
J.H.

Re: [PATCH] gitweb: Refactor project list routines

Reply Threaded More More options
Print post
Permalink
In reply to this post by Petr Baudis
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 <[hidden email]>
>
> ---
>  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();
>  }
>  

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Petr Baudis

Re: [PATCH] gitweb: Refactor project list routines

Reply Threaded More More options
Print post
Permalink
  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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html