This is quite similar to the bug I've described in
http://code.djangoproject.com/ticket/12879 .
There is one thing that definitely needs to be done - Media definition
needs to store javascripts as an ordered set to prevent duplicate
inclusions rather then a list.
I think adding jquery.js to the base.html file in admin is indeed the
proper way to go -
1) It is explicitly included, which seems much better then implicitly
hiding it in {{ media }}
2) I think I will be right if I say that most of the admin widgets are
developed using jquery anyway
3) It will make jquery available of every page, rather then on pages
which meet specific condition. Though that seems kinda controversial,
it will make plugin development much easier, because people will be
able to rely on jQuery being available on every page, rather then on
"some" pages.
4) It won't waste much traffic - considering that only site managers
use admin site + it will get cached anyway
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 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.
