On Feb 19, 1:39 am, Rob Hudson <r...@cogit8.org> wrote: > 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 think that quickly becomes overcomplicated if person wants to use some plugins on top of jquery. You'll need to load them dynamically as well => providing callback will become tricky. Whole libraries were developed to solve that problem - ie LABjs. The underlying issue is the fact that javascript does not have any analogue of "import" statement. > 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.
