Re: [PATCH/RFC 10/10] gitweb: Create links leading to 'blame_incremental' using JavaScript

On Mon, 27 July 2009, Martin Koegler wrote:

On Sun, Jul 26, 2009 at 12:06:11PM +0200, Jakub Narebski wrote:

quoted

On Sat, 25 Jul 2009, Martin Koegler wrote:

quoted

On Sat, Jul 25, 2009 at 12:44:10AM +0200, Jakub Narebski wrote:

quoted

quoted

TODO list:
* Perhaps put fixLinks() function in separate file gitweb.js.
  Should gitweb use single JavaScript file, or should it be split into
  more than one file?

The same question can be asked for gitweb itself:

Well, there is one important difference: gitweb itself is not send
over network to client.  JavaScript is.  (Although I'm not sure how
great it is of an issue, with browsers caching JavaScript.  Perhaps
one single file would be better idea.)

More files mean more request on the server. If the browser is
configured to check at each request, it will issue a GET for each
JavaScript file, which will be answered by a 304 after the first
request. In the "automatic mode", the browser waits for some time
(determined by a heuristic), before it will issue a GET for each file
request again.

So in my option, on (bigger) file is better, as it means fewer request.

I didn't means splitting JavaScript file based on functionality, like
one would do with modules in C, for example.  I was wondering if it 
would be worth to keep gitweb.js with common utility functions and 
functions used in all or nearly all views separate from gitweb-blame.js
which would be loaded and used only for 'blame_incremental' view.

But I am not sure if it is worth complications with build procedure:
installation and configuration.  With single JavaScript file it is
enough to have GITWEB_JAVASCRIPT or GITWEB_JS build variable/option,
and that would be enough.  Not so if we have gitweb-blame.js and 
perhaps other such files.


BTW. we can minify JavaScript file during the build (for example using
JSMin, or one of its derivatives), and e.g. use "gitweb.min.js" in
HTML generated by gitweb.perl / gitweb.cgi.

quoted

quoted

Why is it a single perl file and not splited in many different
modules?

2. Having it all in single file make its easy to install and update.
   Well, it made more sense when only way to configure gitweb was to
   edit gitweb.cgi.  Now building gitweb.cgi is the task for build
   system, and the only thing left is to copy files in correct place
   (I think that there are distribution specific packages which makes
   installing gitweb as easy as "xxx install gitweb").

Yes, there are gitweb packages, which automaticially server
repositories under a specific path (eg. /srv/git). For such packages,
the js layout is irrelavant.

When manually installing, copying only one javascript file simplifies
the deployment.

OTOH if we split Perl source of gitweb (it is second in size only to
gitk; fourth in size git-gui got already split into smaller modules)
then dealing with multiple JavaScript wouldn't be the problem in build.

quoted

3. You would have to decide _how_ to split it into many different 
   modules.  Do you know any good examples?

Javascript uses on global namespace. If it is one file, its implicitly
clear, that everything (functions, variables) are in one scope.  If
you split it into multiple files, you have to remember, what the other
files contain.

True.  You can however use single global object and store what would
be global variables as properties (fields) of such object...

Besides I'm not advocating splitting into many small files.  Only that
much files as really necessary.

-- 
Jakub Narebski
Poland