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:
signature.asc
Description: Digital signature