git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Waitz <tali@admingilde.org>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] gitweb: use common parameter parsing and generation for "o", too.
Date: Fri, 18 Aug 2006 22:20:13 +0200	[thread overview]
Message-ID: <20060818202013.GB30022@admingilde.org> (raw)
In-Reply-To: <200608172134.38751.jnareb@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

hoi :)

On Thu, Aug 17, 2006 at 09:34:38PM +0200, Jakub Narebski wrote:
> > Perhaps we can agree that only the validation should be coupled with the
> > actual user?  E.g. use normal validate_input() for it and then check
> > for actual values inside git_project_list (which is already done now).
> 
> The validate_input() function has too generic name and is too widely used:
> it should be split into validate_ref() and validate_path(); perhaps "o"
> should be validate with $order =~ m/^[a-zA-Z]$/ 

agreed.

> But I was thinking about moving parameter parsing to the "action" functions
> which use them, the opposite of what you want to do...

but only short-term.

I think we both agree on the same target:
we need some simple to pass parameters to a function which should only
be called if the user clicks on a specific link.

Now lets talk about the interface to do this.

We need one interface for generating the URL (stub in RPC talk)
and one for calling the function once the link is clicked (skeleton).
We now have the href() function which is not so bad for the stub side.
We now need a nice generic skeleton.

Perhaps introduce a new function which is used to access the parameters?
This new function could check the URL or CGI->param or whatever and then
return the requested value.

Then the action functions could get all parameters they need, validate
them themselves and then act on them.
This would suit my "break out parameter parsing from actions" and your
"validate parameters in the action function".
(And I really interpret your sentence in such a way that you only want
to move the _validation_, not the actual parsing (which is done inside
CGI->param at the moment.)

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2006-08-18 20:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-16 22:28 [PATCH] gitweb: continue consolidation of URL generation Martin Waitz
2006-08-16 22:28 ` [PATCH] gitweb: use common parameter parsing and generation for "o", too Martin Waitz
2006-08-16 22:28   ` [PATCH] gitweb: support for "fp" parameter Martin Waitz
2006-08-16 22:28     ` [PATCH] gitweb: support for / as home_link Martin Waitz
2006-08-16 22:28       ` [PATCH] gitweb: fix project list if PATH_INFO=="/" Martin Waitz
2006-08-16 22:28         ` [PATCH] gitweb: use action dispatcher for non-project actions, too Martin Waitz
2006-08-17  2:06           ` Junio C Hamano
2006-08-17 15:00             ` Carl Worth
2006-08-18 13:16               ` Petr Baudis
2006-08-18 14:03                 ` Carl Worth
2006-08-18 14:22                   ` Jakub Narebski
2006-08-18 15:40                   ` Petr Baudis
2006-08-17 19:43             ` Martin Waitz
2006-08-17  9:41           ` Jakub Narebski
2006-08-17 19:49             ` Martin Waitz
2006-08-17 20:00               ` Jakub Narebski
2006-08-17  9:35   ` [PATCH] gitweb: use common parameter parsing and generation for "o", too Jakub Narebski
2006-08-17 19:13     ` Martin Waitz
2006-08-17 19:34       ` Jakub Narebski
2006-08-18 20:20         ` Martin Waitz [this message]
2006-08-19 10:55           ` Jakub Narebski
2006-08-19 18:33             ` Martin Waitz
2006-08-19 21:44               ` Jakub Narebski
2006-08-17  1:59 ` [PATCH] gitweb: continue consolidation of URL generation Junio C Hamano
2006-08-17 19:32   ` Martin Waitz

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=20060818202013.GB30022@admingilde.org \
    --to=tali@admingilde.org \
    --cc=git@vger.kernel.org \
    --cc=jnareb@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).