> This kind of sounds nice, but perhaps some sort of django namespace
> could be introduced. Meaning $jQD -> dj.$:
>
>
>
> var dj = {};
> dj.$ = dj.jQuery = jQuery.noConflict(true);
>
This is a great idea, it also means that we could have a setting for
specifying which libraries to add to t
> I like the option (2).
wouldn't it mean that jquery library can potentially get downloaded/
parsed many times, which will slow down the page rendering?
On Feb 22, 7:49 pm, Ales Zoulek wrote:
> I like the option (2).
>
> Could some of you provide a patch for the ticket in the proposed fashion?
I like the option (2).
Could some of you provide a patch for the ticket in the proposed fashion?
Ales
--
Ales Zoulek
+420 604 332 515
Jabber: ales.zou...@gmail.com
--
On Sat, Feb 20, 2010
>
>
> var $jQD = jQuery.noConflict();
>
>
> And somebody else includes this:
>
>
>
> Then Django's version of jQuery would be available to all widgets as
> $jQD and the other jQuery version would still be available as $ or
> jQuery.
This kind of sounds nice, but perhaps some sort of djang
Hello all friends,
I would like to apologize for my inappropriate comments and not
offering constructive criticism.
Sorry, although there are many reasons[1] why jquery sucks for coding
a good and extensible UI for the admin, I realize that it will be
quite impossible to convince any of you about
On Sat, Feb 20, 2010 at 1:58 AM, Rob Hudson wrote:
> On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant wrote:
>> IMO, using 'library agnostic' javascript in the admin will mean we
>> just end up implementing our own library, which will end up being an
>> ad hoc, informally-specified, bug-ridden, slow i
Hi Rob,
On Feb 19, 11:58 am, Rob Hudson wrote:
> On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant wrote:
> 1) Do we put jQuery in base.html and have Django's widgets and plugins
> assume it will be there?
>
> * Benefits: Javascript admin customizations are simpler and can use
> the jQuery already on
On Fri, Feb 19, 2010 at 8:58 AM, Luke Plant wrote:
> IMO, using 'library agnostic' javascript in the admin will mean we
> just end up implementing our own library, which will end up being an
> ad hoc, informally-specified, bug-ridden, slow implementation of half
> of jQuery/dojo/etc, and even less
On Friday 19 February 2010 14:38:01 Rajeev J Sebastian wrote:
> >>> While certain parts of the admin are (or will be) using jQuery
> >>> (widgets, etc.)
> >>
> >> This really sucks. Kindly don't do this.
> >
> > It already does. At least the calendar widget is done with
> > jQuery.
>
> Bad.
Com
On Fri, Feb 19, 2010 at 10:14 PM, Luke Plant wrote:
> On Friday 19 February 2010 15:44:00 Javier Guerra wrote:
>
>> just checked my install, and there's no trace of jQuery anywhere in
>> the admin
>
> You must be looking at an old checkout:
>
> http://code.djangoproject.com/browser/django/trunk/
On Friday 19 February 2010 15:44:00 Javier Guerra wrote:
> just checked my install, and there's no trace of jQuery anywhere in
> the admin
You must be looking at an old checkout:
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L273
Luke
--
Clothes make th
On Fri, Feb 19, 2010 at 10:36 AM, Jannis Leidel wrote:
> The calendar widget [1] is *not* done with jQuery.
ups! my bad i must have misread and misremembered some old
comments somewhere.
just checked my install, and there's no trace of jQuery anywhere in the admin
--
Javier
--
You rece
Am 19.02.2010 um 15:31 schrieb Javier Guerra:
> On Fri, Feb 19, 2010 at 6:32 AM, Rajeev J Sebastian
> wrote:
>> On Thu, Feb 18, 2010 at 8:09 PM, Rob Hudson wrote:
>>> While certain parts of the admin are (or will be) using jQuery
>>> (widgets, etc.)
>>
>> This really sucks. Kindly don't do this
On Fri, Feb 19, 2010 at 8:01 PM, Javier Guerra wrote:
> On Fri, Feb 19, 2010 at 6:32 AM, Rajeev J Sebastian
> wrote:
>> On Thu, Feb 18, 2010 at 8:09 PM, Rob Hudson wrote:
>>> While certain parts of the admin are (or will be) using jQuery
>>> (widgets, etc.)
>>
>> This really sucks. Kindly don't
On Fri, Feb 19, 2010 at 6:32 AM, Rajeev J Sebastian
wrote:
> On Thu, Feb 18, 2010 at 8:09 PM, Rob Hudson wrote:
>> While certain parts of the admin are (or will be) using jQuery
>> (widgets, etc.)
>
> This really sucks. Kindly don't do this.
It already does. At least the calendar widget is done
On Thu, Feb 18, 2010 at 8:09 PM, Rob Hudson wrote:
> While certain parts of the admin are (or will be) using jQuery
> (widgets, etc.)
This really sucks. Kindly don't do this.
Regards
Rajeev J Sebastian
--
You received this message because you are subscribed to the Google Groups
"Django develo
On Feb 19, 1:39 am, Rob Hudson 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 direc
+ it will make changing the jquery version much easier, since the
person can just overwrite the base.html template
On Feb 19, 3:39 pm, George Karpenkov wrote:
> This is quite similar to the bug I've described
> inhttp://code.djangoproject.com/ticket/12879.
>
> There is one thing that definitely
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 b
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
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 p
21 matches
Mail list logo
