On Tue, 30 September 2008, Giuseppe Bilotta wrote: > On Tue, Sep 30, 2008 at 1:22 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> On Tue, 30 Sep 2008, Giuseppe "Oblomov" Bilotta wrote: >>> On Tue, Sep 30, 2008 at 10:48 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >>>> Or we could just scrap and revert adding href(..., -replay=>1). >>>> There is much trouble with getting it right and performing well, >>>> and it is less useful than I thought (at least now). >>> >>> Dunno, the idea in itself is not bad. We just have to get it right ;) >> >> It is not easy to get it right, especially that there are multivalued >> parameters like @extra_options, see e.g. commit 7863c612 > > So we just let values be arrays. Or isn't this enough? I don't think it would be that simple. Let me elaborate a bit about complications and difficulties within href() code. First there are two names of parameters: the short name like 'a', or 'h', or 'f' which is used in links to make them short (and which is a bit historical legacy), and the long names like 'action', 'hash' or 'file_name' which are used for readability; then there are also variables which hold values of parameters, like $action, $hash and $file_name (which were source of long names for parameters). href() has to provide translation between those two (well, three) names; long names are used as names of "named parameters" to href(), while short names are used when generating URL; %mapping provides mapping between those two. Second, href() must distinguish between gitweb options/parameters like 'file_name'=>$file_name and extra options like '-full'=>1 or '-replay'=>1; additionally we want to have options output in some definite order, with more important options first. This is provided by %mapping (to filter out) and @mapping (to sort). Third, there are various sources of values of parameters, and parameters used. There are parameters specified explicitly in href() call, and there are also implicit parameters: 'project' parameter is implicitly added as it is needed in almost all gitweb links (you can override it and generate projectless link by using 'project'=>undef), and for '-replay'=>1 all parameters from current URL are added. Parameters specified explicitly have preference over implicit or '-replay' ones. Now for '-replay' parameters might come from CGI query string, from path_info part of URL, and perhaps in the future also from command line. To avoid duplicated code and other problems we should either get parameters from variables (like in your code, but which doesn't cover @extra_options well, but it could; or using "long name" to variable ref mapping), or have some place where we save parameters as we extract it from CGI query string, from path_info part of URL, and in the future probably also from command line options/parameters. Fourth, there is a little matter of _some_ parameters be multivalued; currently it is only @extra_options / 'opt', but this may change in the future, while _most_ are ordinary scalar values. Printing arrayref isn't something we want to do... That is third and fourth which caused problems in the past with href(..., -replay=>1)... -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
