git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Cc: Christian Couder <chriscool@tuxfamily.org>,
	Petr Baudis <pasky@ucw.cz>,
	git@vger.kernel.org
Subject: About [PATCH 2/2] gitweb: Create a perl module to handle gitweb cgi params and vars
Date: Thu, 3 Jun 2010 10:55:28 +0200	[thread overview]
Message-ID: <201006031055.28966.jnareb@gmail.com> (raw)
In-Reply-To: <201006022229.31593.jnareb@gmail.com>

This comment is about commit a6d54b3 (gitweb: Create a perl module to
handle gitweb cgi params and vars, 2010-06-02) on 'master' branch of
repository shown at http://repo.or.cz/w/git/gsoc2010-gitweb.git

> From a6d54b39cee3d8d39c7ffd993b23e7477d4b0eeb Mon Sep 17 00:00:00 2001
> From: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
> Date: Wed, 2 Jun 2010 01:09:51 +0530
> Subject: [PATCH] gitweb: Create a perl module to handle gitweb cgi params and vars

I would probably say

  Subject: [PATCH] gitweb: Create Gitweb::Request module to handle gitweb cgi params and vars

or even

  Subject: [PATCH] gitweb: Create Gitweb::Request module

so that _name_ of this module is in commit subject (summary).

> 
> Create a perl module in path gitweb/lib/Gitweb/Request.pm
> to store and handle all the cgi params and global variables
> regarding the gitweb.perl script and change the scope of those
> variables in the main script.
> 
> Change Makefile accordingly to install the Perl Module.

Similar comment like for the previous patch.

You would probably want to list which subroutines were moved to
Gitweb::Request, I think.

> 
> Signed-off-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
> ---

This patch would be probably based on 'next', and this should be
mentioned in this area, in comment about patch.

>  gitweb/Makefile              |    1 +
>  gitweb/gitweb.perl           | 1245 ++++++++++++++++++++----------------------
>  gitweb/lib/Gitweb/Request.pm |   58 ++
>  3 files changed, 662 insertions(+), 642 deletions(-)
>  create mode 100644 gitweb/lib/Gitweb/Request.pm
> 
> diff --git a/gitweb/Makefile b/gitweb/Makefile
> index 45e176e..15646b2 100644
> --- a/gitweb/Makefile
> +++ b/gitweb/Makefile
> @@ -113,6 +113,7 @@ GITWEB_FILES += static/git-logo.png static/git-favicon.png
>  
>  # Files: gitweb/lib/Gitweb
>  GITWEB_LIB_GITWEB += lib/Gitweb/Config.pm
> +GITWEB_LIB_GITWEB += lib/Gitweb/Request.pm

Nice.

> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 98a85f4..263af48 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -26,6 +26,7 @@ sub __DIR__ () {
>  use lib __DIR__ . "/lib";
>  
>  use Gitweb::Config;
> +use Gitweb::Request;

Nice.

> @@ -33,42 +34,6 @@ BEGIN {
>  
>  our $version = "++GIT_VERSION++";

The above context line changed wrt. original patch, to follow the idea
about exporting variables by default in Gitweb::Config, and not using
fully qualified variable names.

>  
> -our ($my_url, $my_uri, $base_url, $path_info, $home_link);
> -sub evaluate_uri {
> -	our $cgi;

I guess that $cgi is left for gitweb.perl, isn't it, because it
depends on FastCGI vs CGI?  [reads later part].  I guess not, only
$CGI is left in gitweb.perl.

[...]
> -}

O.K. these variables, and evaluate_uri() is moved to Gitweb::Request.

[removed changes related to introducing fully qualified variable
 names; it would make patch smaller without those]

> @@ -347,13 +312,11 @@ our %allowed_options = (
>  # build an array of parameters that can be multi-valued, but since for the time
>  # being it's only this one, we just single it out
>  sub evaluate_query_params {
> -	our $cgi;
[...]
>  }

> @@ -361,12 +324,12 @@ sub evaluate_query_params {
>  # now read PATH_INFO and update the parameter list for missing parameters
>  sub evaluate_path_info {
[...]
>  }

>  sub evaluate_and_validate_params {
[...]
>  }

Shouldn't evaluate_query_params(), evaluate_path_info(), and the
subroutine that ties them together evaluate_and_validate_params() be
in Gitweb::Request too?

>  
>  sub evaluate_git_dir {
[....]
>  }

Ditto with evaluate_git_dir()?

BTW. as I said in comment to previous patch, vriables such as $project
should be put in Gitweb::Request in my opinion, not in Gitweb::Config.
Perhaps they are, but it is not obvious from this patch.

>  
>  our (@snapshot_fmts, $git_avatar);
> @@ -643,32 +605,32 @@ set_message(\&handle_errors_html);
>  
>  # dispatch
>  sub dispatch {
[...]
>  }
>  
>  sub run_request {

Those two subroutines should not, I guess, be put in Gitweb::Request.
They would be in catch-all Gitweb module, I guess, or perhaps in the
later post-GSoC future in Gitweb::Dispatch or something.

> @@ -689,7 +651,6 @@ sub run_request {
>  our $is_last_request = sub { 1 };
>  our ($pre_dispatch_hook, $post_dispatch_hook, $pre_listen_hook);
>  our $CGI = 'CGI';
> -our $cgi;
>  sub evaluate_argv {
>  	return unless (@ARGV);

Ah, so $CGI is left in gitweb.perl, $cgi is moved to Gitweb::Request.
  
[cut more than half of patch, which sould not be needed with exporting
 variables and not using fully qualified variable names]

> diff --git a/gitweb/lib/Gitweb/Request.pm b/gitweb/lib/Gitweb/Request.pm
> new file mode 100644
> index 0000000..91cc492
> --- /dev/null
> +++ b/gitweb/lib/Gitweb/Request.pm
> @@ -0,0 +1,58 @@
> +#!/usr/bin/perl
> +#
> +# Gitweb::Request -- gitweb request(cgi) package
> +#
> +# This program is licensed under the GPLv2

I don't remember what is git policy on copyright statements, and on
GPLv2 vs GPLv2+...

> +
> +package Gitweb::Request;
> +
> +use strict;
> +
> +BEGIN {
> +	use Exporter();
> +
> +	@Gitweb::Request::ISA = qw(Exporter);	
> +	@Gitweb::Request::EXPORT = qw();
> +}

Same comment as for previous patch.

   use Exporter qw(import);
   our @EXPORT = qw($cgi, $my_url, $my_uri, $base_url, ...);

BTW with exporting variables you can easily see here that
Gitweb::Request does not use any variable from Gitweb::Config.

> +
> +our ($cgi, $my_url, $my_uri, $base_url, $path_info, $home_link);
> +our ($action, $project, $file_name, $file_parent, $hash, $hash_parent, $hash_base,
> +     $hash_parent_base, @extra_options, $page, $git_dir);
> +our ($searchtype, $search_use_regexp, $searchtext, $search_regexp);
> +
> +sub evaluate_uri {
[...]
> +}

Straightforward code movement.  But see comment above on which
subroutines I feel should be also put in Gitweb::Request.

-- 
Jakub Narebski
Poland

  parent reply	other threads:[~2010-06-03  8:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02 20:29 About [PATCH] gitweb: Create a perl module to store gitweb configuration Jakub Narebski
2010-06-03  5:07 ` Pavan Kumar Sunkara
2010-06-03 10:23   ` Jakub Narebski
2010-06-03  8:55 ` Jakub Narebski [this message]
2010-06-03  9:52   ` About [PATCH 2/2] gitweb: Create a perl module to handle gitweb cgi params and vars Pavan Kumar Sunkara
2010-06-03 10:17     ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201006031055.28966.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=pasky@ucw.cz \
    --cc=pavan.sss1991@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).