The problem of including javascript files/libraries was discussed
quite a few times on this mailing list. (the problems start to appear
when two or more reusable apps are used on the same page and both of
them reference same javascript libraries, thus conflicting with each
other )
The overall consensus was to use class Media js declaration to include
them. It solves quite a lot of problems, but unfortunately, not all of
them. Namely, a few annoying things I see are:
1) There is no centralized way to specify paths to the libraries. IE
if admins for A, B, C, D and E use jquery-ui, the tutorial encourages
adding the declaration 'js = ("%(MEDIA_URL)s/js/jquery-ui.js")' to
each admin file. However, later on if the js file is moved to, say
media/js/external/libraries/jquery-ui.js one would have to go through
every admin file and manually search for all the references.
Furthermore, if one decides to include an external app (say, "appA")
in his project, and it also happens to use jquery-ui he will have to
once again manually look through all the admin.py files (or any files
which can modify them) and make sure that they all reference "his"
jquery-ui, not the jquery-ui which was bundled with appA (because
otherwise there is a potential of conflict between the two, should
they both appear on the same page)
2) Media declarations are quite annoying with regard to inheritance.
If class A inherits from B, C, D and E then it should include the line
js = (B.Media.js + C.Media.js + D.Media.js + E.Media.js), which can
become painful if someone decides to change the inheritance structure.
3) Admin apps can use external apps (usually through templatetags)
which do not have the chance to pass their media through Admin.Media
class, so there is no clear way to resolve potential conflicts.
4) As an extension on 3), this solution seems admin-specific, while
the problem of conflicting libraries is definitely not restricted to
the admin. Django encourages the use of reusable apps. They can be
used on the same page, through {% include %}'s or templatetags. If two
apps reference same libraries, namely, the one which use plugins,
there is a huge potential for conflict.
One idea I was thinking about is to have {% include_js %} templatetag,
which will reference libraries by the name & version rather then
location, take care of removing redundant declaration via keeping an
array of already included files in the template state variable and
mapping the names of the files to path through some variable in some
file (either something like JS_LIBRARIES in settings.py or somewhere
else). That approach would solve all of the problems described in
1)-4). To keep the backwards compatibility with the Media declaration
in the admin files, the admin system could simply add those
templatetags to the output.
So the overall proposed syntax is along the lines of
{% include_js <library_name> <version_number or latest> <location -
local or remote> %}
Which introduces additional benefits:
1) declaration like {% include_js dojo latest %} make it really easy
to upgrade the library - just changing the path in the settings will
do the trick
2) it makes it really easy to switch between the production mode
(where quite a lot of people prefer to host their js library on some
cloud - ie google) and the development mode (where you want the
library stored on your computer)
Thoughts / ideas?
Regards,
George
--
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.
