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

[Jakub Narebski <jnareb@gmail.com>]

On Mon, 27 July 2009, Martin Koegler wrote:
> On Sun, Jul 26, 2009 at 12:06:11PM +0200, Jakub Narebski wrote:
>> On Sat, 25 Jul 2009, Martin Koegler wrote:
>>> On Sat, Jul 25, 2009 at 12:44:10AM +0200, Jakub Narebski wrote:
>> 
>>>> 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.

>>> 
>>> 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.

> 
>> 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