{"thread":{"id":"4616","subject":"gitweb refactoring","startedAt":"2006-06-22T15:30:04Z","lastAt":"2006-06-22T18:37:48Z","messageCount":2,"participants":["Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"22281","messageId":"e7ed1r$9ve$1@sea.gmane.org","threadId":"4616","inReplyTo":null,"subject":"gitweb refactoring","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-22T15:30:04Z","receivedAt":"2006-06-22T15:30:04Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski <jnareb@gmail.com> writes:\n> > Jakub Narebski wrote:\n>>\n>>> * Refactor generation of navigation bar. There are at least two\n>>>   implementations of that. With hash dispatch it would be easy to\n>>>   list all possibilities.\n>>\n>> Actually I think that whole gitweb.cgi needs refactoring, badly.\n>> Generation of navigation bar is only one, admittedly worst, \n>> example of code duplication.\n> \n> Yes.  I liked what xmms2 folks did to the navbar exactly for\n> that reason.  We would be better off to first clean up what we\n> currently have before starting to build too much on it.\n\nSo lets talk about gitweb refactoring.\n\nCurrently gitweb subroutines can be divided into following categories:\n\n1. \"Action\" subroutines, which do all the work, i.e. they output whole\ncontents of the page. Currently they are named git_$action, e.g.\ngit_summary(), git_log(), git_blob(), git_heads(),... , git_blame(). \nThe list includes \"hidden\" actions, namely git_logo(), git_opml(), and\ngit_project_list(). There is nothing 'git' about those subroutines.\nHow should they be named? What prefix to use? action_summary(),\nwrite_summary(), output_summary(), out_summary(), gitweb_summary()?\n\n2. Miscelanous \"HTML\" subroutines, outputting fragments of HTML code, like\ngit_header_html, git_footer_html and die_error; or returning fragment of\nHTML code, like format_log_line_html. Refactoring should put all the work\ninto such subroutines.\n\n3. Many helper subroutines: \n  - related o HTML or HTTP: esc_param, esc_html, mimetype_guess_file, \n    mimetype_guess, git_blob_plain_mimetype, age_class\n  - mangling git output: unquote, age_class, age_string, mode_str, file_type\n  - other helper subroutines: chop_str, date_str, get_file_owner, \n    validate_input\n\n4. Subroutines which invoke git commands, usually using \"-|\" LIST magic\noutput call: git_get_type($hash), git_get_project_config($key) and\ngit_get_project_config_bool($key), git_get_hash_by_path($base, $path).\n\nIncluding git_read_tag($hash) and git_read_commit($hash) which fills\n%tag/%co object with information from parsing tag/commit.\n\nUnusual in this set git_read_head($project) which sets $ENV{GIT_DIR}\ntemporarily and git_diff_print($from_id, $from_name, $to_id, $to_name,\n$format = \"html\") which does the work for blobdiff and blobdiff_plain using\ntemporary files (new git probably can do this without need for temporaru\nfiles)\n\n5. Subroutines which directly access git repository, sometimes calling\nsubroutines mentioned above, including: git_read_hash (which needs\nrefactoring itself I think), git_read_description, git_read_projects,\nread_info_ref, git_read_refs (instead of using git-branch or git-tag -l,\nwhich also parses information into %ref_item hash).\n\n6* Listed in the sets above are suroutines which parse info into hash or\narray of hashes/hashrefs: git_read_tag, git_read_commit, git_read_refs.\nOther multi-line output like 'ls-tree' output is parsed and output line by\nline. \n\n\nSome of those subroutines probably will find the way to Git.pm. But in all\nthey need to be cleanly separated into classed if possible, and reworked to\ndo one thing and do it well. Passing parameters instead of relying on\nglobal variables would help porting to mod_perl, for example.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"22288","messageId":"e7eo1r$j87$1@sea.gmane.org","threadId":"4616","inReplyTo":"e7ed1r$9ve$1@sea.gmane.org","subject":"Re: gitweb refactoring","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-22T18:37:48Z","receivedAt":"2006-06-22T18:37:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Another approach to refactoring gitweb would be to look at it's output.\nCurrently (with the exception of summary view), we have four main types of\nviews:\n\n1. 'short listing' view, using zebra tables, which list \"objects\", each with\nsome number of columns usually not hyperlinked, object name/title,\nsometimes shortened, sometimes post-processed which is link to the object,\nthen some object related links. Actions using this type of view: shortlog,\nhistory, tree, tags, heads, blame; files affected part of commit view.\nExamples of columns:\n  Age, Author, Title[*1*] (link), commit|commitdiff    for shortlog\n  Mode, Filename (link), tree or blob|history          for tree\n\n2. 'single object' view, with fixed number of blocks. Actions using this\ntype of view: commit, tag.\n\n3. 'long listing' view, which list \"object\"; description of each object\ntakes more than one line. Actions using this type of view: log, search.\n\n4. 'large object' view, in which \"object\", optionally with some header, is\nwritten line by line, with some syntax highlighting, sometimes with line\nnumbering, with at least one div per line. Actions using this type of view:\nblob, commitdiff, blobdiff. Currently diffs are not splitted into chunks at\nthe HTML level (chunks are not encompassed in div; perhaps they should,\nperhaps not - HTML like header structure vs DocBook nesting).\n\n5. 'other' non HTML output, including blob_plain, commitdiff_plain,\nblobdiff_plain, rss, opml, git_logo; perhaps in the future commitdiff_email\n(for git-am or sending to the list), snapshot (tar, tar.gz, tar.bz2),\ngit_favicon.\n\n\nSome views have subviews of other type.\n\n\nPage as whole consist of:\n* page header (which includes searchbox, what is not obvious) with \n  breadcrumbs up to action, \n* two part navigation bar: \n  - first part is always single hash action listing\n      summary | shortlog | log | commit | commitdiff | tree \n    with and exception of base (first) commit which doesn't have commitdiff.\n  - second part is either \"pager\" for log and shortlog, i.e.\n      HEAD . prev . next\n    or \"type selection\" for commitdiff, blobdiff and blob, sometimes\n    including head (why not HEAD?).\n* sometimes empty title of current hash or hash_base (current commit),\n  or empty and linking to summary page.\n* path (filename) header for tree and blob\n* body of the page\n* page footer with project description, and RSS link.\n\n\n[*1*] Processed and shortened title (first line of commit), tooltip using\ntitle attribute of link if shortened (gitweb-xmms2 broke that with\nntroduction of committags), tags which references this commit shown (now\nonly for summary I think, and tag(s) length is not taken into account when\nshortening title/oneline description)\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}