On Fri, Jan 28, 2011 at 10:18 PM, Fabian Büchler <[email protected]> wrote: > Hello Django developers, > > as this is my first post here, let me shortly introduce myself: > I'm Fabian Büchler, webdeveloper from Vienna, Austria; relatively new to > Django and just thinking about hacking on Django itsself ... > I've read all your contribution guidelines and I believe this to be the > correct place for my concern - please correct me if I'm wrong.
You've found the right place - and welcome! > I have a suggestion for improvement to the Django admin, namely the > DateTimeShortcuts - especially in combination with model inlines. > > The big picture > In a project I'm working on an event management tool for the Vienna tourist > board and one of our models is heavily date based: > Event 1<n EventDate (used in a tabular inline within Event change forms). > > Each EventDate has two date fields and two time fields, that means four > date/time pickers per inline row. > When adding new rows using the "Add new row" link, this is already quite > slow. The more inline rows are on the page, the slower it gets. > > In addition to that, I've built a generator tool for these inlines which > generates EventDates by requested patterns (per weekday, for a certain date > range,...). > When generating more than a hand full of inline rows at a time, the browser > slows down to a halt - continuous JS timeouts included. > > All this happens on multiple, relatively new computers (all OSes), in the > newest browsers (FF3.6, FF4b10,...). > After some JS profiling I found, that the problem seems to be burried within > the reinitialization of all .datetimeshortcuts every time a new inline row > is being added. > The processing of that takes about 95% of the overall JavaScript processing > time. > > My improvement suggestion > As a solution I would suggest to rewrite the complete DateTimeShortcuts.js > using jQuery (it is not jQuery based at all atm.), especially jQuery's new > (1.4.2) event delegation functionality [0] to improve performance. With > event delegation, no reinitialization of newly added .datetimeshortcuts > elements would be necessary at all. > As an addition, I think it would make sense to integrate the jQuery UI > datepicker (maybe with a timepicker extension [1]) instead of the existing > one, because that might resolve some problems, as with the datepicker > opening outside of the viewport when the calendar icon is too far on the > right side of the screen. > > I am willing to try to implement this myself (and, of course, provide any > outcomes to the community). > But before starting, I first wanted to hear your opinions to my suggestion > and - if accepted - any pointers to how you would like this to be > implemented. For some background -- Django's admin started as a hand-crafted Javascript solution -- mostly because it predates the existence of jQuery as a widely accpted javascript framework. We only added jQuery to the admin around a year ago. As a result, there is an admin javascript cleanup needed. Updating date/time handling is part of that. The best way to approach this is to Just Do It. Pick some specific aspect of the Javascript where you think a jQuery-based cleanup is called for, prepare a patch, then open a ticket and upload your patch to that ticket. Try to constrain the scope of your changes if you can. Don't just drop a "I've fixed all your Javascript" patch on our laps -- if you start smaller, it's a lot easier for us to give feedback. As for using JQueryUI -- we don't currently have that dependency, so you'll have to make your case for why we should add the new dependency. If you can show a sample implementation that saves X% of code, or is Y% faster, or has new features ABC, that will go a long way to making your case. So - thanks for offering to help out! Can't wait to see the improvements you can make. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
