i forgot to add this feature to employ javascript syntax highlighter to pretty-print contents of the blob view.Here are my views regarding which library to use . i want to stick to one or two libraries as i dont want to mix things up which is a bad practise. for DOM manipulation jquery is better than others. for graphics representation raphael library or Dojo is better. if one need robust Object oriented platform , Dojo is better. Based on popularity , light weighted library jquery is pretty famous because of its simplicity and power ,it got added advantage that microsoft Asp.net and nokia are supporting it. YUI is modular . mootools lets have us our own way .. http://jqueryvsmootools.com/ please take a look at this Link. http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks. Based on the goal of the project , i would prefer jquery as it is well tested ,robust , simple to use , widely popular,good support for DOM manipulating , fast(performance) in most cases , even though for graphics i would go for raphael as it have clean and neat api similar to jquery , it has good graphics support. please enlighten me if i'm going on the wrong track. I am sure you will :) On Wed, Mar 28, 2012 at 4:08 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html