I've been thinking about this ever since I learned that django's
admin
was going to be using jQuery, but I admit I didn't really consider
it
that important until recently (building sites against 1.2-beta).
I know now is not a fantastic time to be talking about features, but
this is something I'd enjoy working on (personally), and I am just
hoping to get a little feedback regarding the design, and how it
might
fit in with everything else going on in django's guts
(philosophically). I also understand that this isn't something
for near
versions of django, but rather the distant future.
Here's where the pin dropped:
* The jQuery used by the admin site is conjured using the no
conflict
option and is relegated/isolated to it's own namespace (excellent).
* There are many projects/apps out there that also rely on jQuery
- they
also "bundle" the framework, but may not be quite so quick to play
nice.
In my case, I noticed that when I added a few jQuery-enhanced form
widgets to a form in my admin site, it resulted in 3 instances of
the
framework being sourced in the document head. Although, this is
actually ok for the most part in terms of operation (so long as the
scripted events that come with each widget are bound to the dom
before
the plugin of origin gets wiped by the next sourcing of jQuery),
it's
far from ideal.
There are a myriad of ways to skin this cat, be it a simple
recommendation to adopt the use of django's jQuery and a
template tag
to provide access to the appropriate script tag, or something more
structured/engineered/formal ....
My goal would be to provide app developers with scaffolding to add
javascript/css resources to the rendered view in a non-competitive
way.
I'm thinking in terms of a template tag that works along the lines
of {%
include %}, but for script and link tags, allowing folks to add
scripts
with an optional way to influence the position in the "stack". A
similar interface would also be provided for form media, and perhaps
some kind of helper or shortcut for ease the addition of these
scripts
from our view functions.
I understand that Django has historically been
anti-javascript-framework-blessing, and I'm wondering if opening
this
can of worms would mean having to incorporate some kind of a
pluggable
backend system (for working with different frameworks, or multiple
frameworks at a time) - something I've briefly considered, but
started
foaming at the mouth as a result.
I've also considered the fact that the reaction here might be, "just
don't - leave it all in the individual's hands".
In closing... don't hit me!
Regards,
Owen Nelson
--
You received this message because you are subscribed to the Google
Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com
.
For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en
.
