Re: GSoC idea: adding JavaScript library / framework in gitweb

> On Tue, 27 Mar 2012, chaitanyaa nalla wrote:
>
>> Dear Jakub,
>>
>> I prepared a schedule for gsoc ,please take a look and suggest me in
>> case if you feel some tasks couldn't be completed with in indicated
>> time .
>>
>> Week 1  understanding how the whole gitweb and related server side
>> scripts are implemented , their design philosophy , coding standards ,
>> documentation standards to maintain the best practise coding
>> practices.
>
> I think you need to at least skim the JavaScript part of gitweb code
> to be able to create a decent proposal.
>
>> Brainstorming sessions regarding which libraries to use on
>> specific scenarios by keeping many criteria’s in mind and creating an
>> abstract design on the additional features  that have to be added.
>
> I think it would be a good idea to propose JavaScript library / framework
> to use for client-side scripting in gitweb (jQuery, MooTools, Dojo, YUI),
> explaining shortly why this one and not other (popularity, "weight", your
> knowledge, etc.).  Though perhaps not commit to said library.
>
> You say "libraries", but I think gitweb should use single JavaScript
> library, perhaps with exception of specialized libraries or plugins for
> extra stuff like Raphael.js for drawing.
>
> Also here or later there should be time for short discussion about
> marrying use of external JavaScript library to gitweb.perl script and
> to our build system (gitweb/Makefile).
>
>> Week 2  Improving Javascript browser detection and incremental blame.
>
> Errr... gitweb does not employ browser detection.  Well, at least not
> in strict sense; it does employ some feature detection e.g. to create
> XmlHttpRequest -- but that is what library is for, it is assumed to do
> cross-browser behavior for us.
>
> Anyway improving existing features, and adding new features should be
> much later.  The very first thing is to transform existing code (JavaScript
> detection, adjusting timezones and incremental blame) from hand written
> JavaScript to using JavaScript library, incrementally if possible, and
> removing our own mini-library in `gitweb/static/js/lib/`.
>
> [...]
>> Week 3 Improving UI of adjusting timezone by deciding which library /
>> framework to use on UI.
>
> I don't think timezone select UI needs much improvement.
>
> Anyway I think that we would either use library, or UI addons for library
> (like jQuery UI if you choose jQuery), or plugins for library.
>
>> Week 4 & 5 design and implementation of client side sorting of tables
>
> That should be fairly easy (though I am not sure if "1 week" easy).
> This is what "sorttable" does in jQuery and I guess also other libraries
> (built-in or via plugin); what needs to be adjusted is replacing or
> overriding (perhaps via onclick handler) links to server-side sorting
> by trigger to client-side sorting.  Keeping table zebra-colored might
> be a problem, but I think JavaScript libraries solved that already.
>
>> and client side syntax highlighting of the blob view by handling how
>> git web splits the output into lines and providing line numbers.
>
> That can be hard, and here there might be question of choosing separate
> library for JavaScript-based source highlighting.  There is also a
> question of integrating it with server-side source highlighting (turning
> off JS-based if server side already does syntax highlighting, and using
> the same CSS).
>
>> Week 6  testing the code robustly on as many browsers as possible
>> (with their versions) and documenting the code neatly .
>
> This is a good idea.
>
>> MidTerm Delivarables : Improving javascript browser detection,
>> incremental blame,ui of adjusting timezone .Adding client side sorting
>> of tables and client side syntax highlighting of blob view .
>
> I would be happy if at midterms you would have existing JavaScript
> features ported to JavaScript library, without adding any new features
> or extending existing ones.
>
>> Week 7 & 8 Using deferrands or queues in the interactive blame to
>> avoid the editing of DOM which happens asynchronously to avoid
>> locking
>
> O.K.  You will have to check chosen JavaScript library documentation
> for its name for such things; different libraries uses different names
> for asynchronous processing helpers.
>
> This might be hard part, but if you think you can do it in week
> or two...
>
>> and automatic extending of clickable area for places where the
>> link is constrained to a single cell or of that type.
>
> Nice.  This also means that on server side we can remove link within
> link (which does not work in some overly strict web browsers), but
> this server-side change doesn't need to be done by you.
>
>> Week 9 & 10 & 11 design and implementation support for graphical
>> representation of history in log ,shortlog and history using Raphael
>> javascript library, adding UI to compare arbitrary commits in the page
>> using commitdiff view similar to MediaWiki page history view and
>> creating a side by side diff from unified diff in javascript so that
>> switching between unified diff and side by side diff could be handled
>> on client side.
>
> O.K., though graphical representation of history might be harder than
> that (than allowed 1 week or 2).
>
> Side-by-side diff is just porting from Perl to JavaScript.
>
>> Week 12  documentation , writing a detail report , testing
>> exhaustively and checking whether the written code follows the
>> characteristics .
>> Note: considerable amount of time will be spent each week
>> concentrating on design for adding a new feature since its design
>> greatly affects many things.
>
> --
> Jakub Narebski
> Poland