ok, first i will think and come up with good ideas and then ask you about your suggestions :) On Sat, Mar 24, 2012 at 9:39 PM, chaitanyaa nalla <nallachaitu@xxxxxxxxx> wrote: > Dear Jakub , > > could you please suggest any other ideas or features so that i can > think upon them and come up with further good ideas. > > On Sat, Mar 24, 2012 at 6:47 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> On Sat, 24 Mar 2012, Chaitanyaa Nalla wrote: >> >>> Hello everyone, >>> >>> I am Chaitanya Nalla, a final year undergraduate student from India and I >>> am pretty much interested in doing the project "Adding javascript library / >>> framework in gitweb" suggested by respected Jakub. I have good experience >>> in javascript libraries like jQuery, Dojo etc. As per the goals of the >>> project I will use the efficient, concise, cross browser compatible >>> frameworks where ever needed. >> >> JavaScript library / framework is required not only to cover differences >> between web browsers in DOM manipulation, event handling and Ajax with >> XmlHttpRequest, but also add features which are still[1] lacking from >> JavaScript such as handling cookies, formatting strings, date manipulation, >> etc. >> >> Currently gitweb uses hand-crafted micro-library in `gitweb/static/js/lib/` >> Using existing JavaScript library, be it jQuery (most popular), Dojo, >> MooTools or YUI (probably too much for gitweb) will give us, as you said, >> well tested code, and new abilities like client-side sorting of tables >> which we would be able to use in further work. >> >> [1] http://www.nczonline.net/blog/2011/10/03/when-web-standards-fail-us/ >> >>> Also I am planning to create a local library >>> version with support for configuration and a good documentation. >> >> I don't quite understand what you mean here. The JavaScript code specific >> to gitweb would have to be modified to use chosen JavaScript library, but >> I wouldn't say it is "local library". I'd rather we use stock JavaScript >> library, which would allow us to leverage existing CDNs like (for jQuery) >> >> http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js >> http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js >> http://code.jquery.com/jquery-1.7.2.min.js >> >> We probably would ultimately need to be able to serve local fallback copy >> (but this might be out of scope of GSoC project). >> >> This gitweb-specific JavaScript code (files in `gitweb/static/js/`) >> is IMVHO quite well documented using JSDoc. >> >>> Using the DOM features of JavaScript and traversing the whole document >>> object is quite cubersome and error prone, so I want to replace them using >>> well tested libraries that are cross browser compatible. >> >> I think there is missing "using hand-crafted code" in this sentence >> to make it sense. >> >>> >>> Emulating onprogress in XMLHttpRequest : >>> >>> jQuery and YUI provide only statuses success and error. >> >> Right. >> >>> Even MooTools provide progress but are constrained to some browers >>> only. >> >> To be more exact MooTools support 'onprogress' event handler only if >> web browser supports it. Not all do (e.g. older browsers), that is why >> there is need for emulation using timers. >> >>> It can be handled by using $.ajax Transport utility . >> >> You mean in jQuery here, isn't it? It would be a bit different, I think, >> in MooTools or YUI. >> >> C.f. http://stackoverflow.com/questions/5652229/javascript-framework-with-or-easily-extendable-with-support-for-xmlhttprequest >> >>> I will also take care progressive enhancement, by carefully implementing the >>> basic functionality of the gitweb so that what ever may be the browser >>> version and type, internet connection the basic functionality will not >>> disrupted. >> >> Errr... "progressive enhancement" is about using client-side scripting >> in such way, that even if web browser doesn't support JavaScript >> (e.g. text browsers such as lynx, elinks or w3m), or has JavaScript >> turned off or blocked, we would get a basic functionality. >> >> Note also that "progressive enhancement" part applies only to writing >> new features, and this is strictly 'as time permits' part, I think. >> But I thin that you would need to lay more complete proposal, i.e. >> what features are you planning to add. >> >> -- >> 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