From: Jakub Narebski Date: Sat, 20 Jun 2009 19:24:31 GMT Subject: Re: [PATCHv2] gitweb: gravatar support Message-ID: <200906202124.33278.jnareb@gmail.com> In-Reply-To: <7v63esklxh.fsf@alter.siamese.dyndns.org> On Fri, 19 June 2009, Junio C Hamano wrote: > Giuseppe Bilotta writes: > I see these repeated patterns in your patch. > > > @@ -4145,7 +4179,7 @@ sub git_shortlog_body { > > my $author = chop_and_escape_str($co{'author_name'}, 10); > > # git_summary() used print "$co{'age_string'}\n" . > > print "$co{'age_string_date'}\n" . > > - "" . $author . "\n" . > > + "" . git_get_gravatar($co{'author_email'}, 16, 1) . "" . $author . "\n" . > >... > > - "" . $author . "\n" . > > + "" . git_get_gravatar($co{'author_email'}, 16, 1) . "" . $author . "\n" . > >... > > - "" . $author . "\n" . > > + "" . git_get_gravatar($co{'author_email'}, 16, 1) . "" . $author . "\n" . > >... > > - print "author" . esc_html($co{'author'}) . "\n". > > + print "author" . esc_html($co{'author'}) . "". > > + "" .git_get_gravatar($co{'author_email'}) . "\n" . > >... > > - print "committer" . esc_html($co{'committer'}) . "\n"; > > + print "committer" . esc_html($co{'committer'}) . "". > > + "" .git_get_gravatar($co{'committer_email'}) . "\n"; > >... > > Doesn't it strike you as needing a bit more refactoring? The first three > are identical, and you can refactor them to > > - "" . $author . "\n" . > + "" . oneline_person($author) . "\n" . > > where oneline_person is > > sub oneline_person { > my ($me) = @_; > return ($me->{'smallicon'} . > "" . $me->{'name_escaped'} . ""); > } [...] Well, gitweb certainly needs some love^W refactoring. That is only one of areas. But should we postpone introducing new features till gitweb gets cleaned up? Although in this case I guess we can do cleanup during introduction of new feature (which makes stronger case for factorizing common elements, as they just get larger, those common elements, now with this feature). > That way, people who do not like italics, or people who want to have the > icon at the end instead of at the beginning, can touch only one place > (i.e. "sub oneline_person"). About using presentational HTML: I think one reason behind keeping it is to have gitweb work also in text browsers like lynx, w3m or lynx, which can not understand CSS. [...] > In the medium term, we may want to go one step further and do > > package person; > > and make sets of methods like "oneline_person". That would be first in gitweb. BTW. Should we split gitweb into packages? Should we split gitweb into separate files (one package per file)? -- Jakub Narebski Poland