Thanks for the super fast reply, Russ! the way you put it makes sense to me, so I guess I'm going to start over with replacing just the DateTimeShortcuts script and trying to use that from within the inlines script.
Regards, Fabian 2011/1/28 Russell Keith-Magee <[email protected]> > 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]<django-developers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- 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.
