I've battled many of these same issues when working on the debug toolbar... it needs to work the same in any environment it gets loaded into and, as such, has slightly different requirements put on it. It is seeming the admin is heading the same direction to some degree. While certain parts of the admin are (or will be) using jQuery (widgets, etc.) there's the potential that someone has skinned the admin in such a way that they need an admin with Prototype, for example, to function. That's leading me to think admin widgets and plugins need this same level of encapsulation.
On the ticket I posted a bit of skeleton javascript code that shows how to completely encapsulate both jQuery and widget code into a closure. It's seeming like a good idea to take this approach for all widgets and plugins that are developed for Django. It goes the extra step of checking a minimum version of a pre-existing jQuery and passes in a boolean whether or not jQuery was loaded from Django or provided via custom JS by the developer. I don't know if those are needed exactly, but it's there. This is the basic structure I'm now using for the debug toolbar and it's working well. Happy to help in some way on this if I can. -Rob On Thu, Feb 18, 2010 at 2:20 AM, Ales Zoulek <ales.zou...@gmail.com> wrote: > Hello, > there a ticket about jQuery in admin that breaks any site-included jQueries > and there's no easy/clean way to prevent it. > http://code.djangoproject.com/ticket/12882 > > Let's see a bigger picture there. > To my knowledge, admin has two ways how to include custom JS. One template > based second py-api based: > 1] base_site.html (or other top level template) > 2] ModelAdmin.Media class > First forces user to copy at least part of the html code to his own project > templates. Second allows only per-model javascripts. (Please note that none > of them solves the bug reported in a ticket.) > > > I'd see to possible ways how to fix the ticket. > - Quick and easy: > For some reason, admin uses the ModelAdmin.media to contruct it's own list > of javascripts. Isn't it safe to say that admin has a fixed set of JS libs > it uses and include them on all pages in base.html? > It seems to me safer and more straight-forward behaviour then including > "some.js" if ModelAdmin has some actions, and "some-other-lib.js" if > ModelAdmin.opts.get_ordered_objects(). It makes a bit difficuilt to prevent > javasript name conflicts in site-wide javascripts. I'd propose > that ModelAdmin.media would serve only for apps, not to admin itself and all > admin's JSs would be included in base.html. > The down part is ofcourse thirtd party apps, that can cause some JS > collisions, but its at least easier to control which app I install and what > templates/js it uses or overwrites, and they don't "magicaly" intrude their > js in every change list page. > > - Not so quick and definitely more controversial > What I'd really like is to have some means how to affect admin's behaviour > per-project (not only by redefining admin templates). > That would include overriding it's JS inclusion paths, but other things as > well (global actions, extra context, items per page in change list, etc...) > > > What are your thoughts about that? > > > Regards, > Ales > ------------------------------------------------------ > Ales Zoulek > +420 604 332 515 > Jabber: ales.zou...@gmail.com > ------------------------------------------------------ > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- -Rob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
