Re: django-ajax-selects lintian errors/warnings

[Brian May <bam@debian.org>]

Neil Williams <codehelp@debian.org> writes:

> Then the reference needs to be inserted by a templatetag which knows
> about the running configuration.
>
>> Also, bootstrap.js is also a static file, so we cannot use
>> {{ STATIC_URL }} here.
>
> If it's also a static file, that's exactly what {{ STATIC_URL }}
> provides. It's a static file owned by django-ajax-selects, so
> {{ STATIC_URL }} is correct within d-a-s and the file just gets replaced
> by a symlink to the min.js of the external package during install. The
> URL is the .min.js but the editable .js is provided in VCS.

errr.. It is static. Meaning it is served by Apache without any help
from Django. Meaning none of Django's template stuff will work inside
bootstrap.js, because Django's template stuff doesn't get
invoked. Meaning we cannot use {{ STATIC_URL }} in this file.

Referencing bootstrap.js is easy. However getting bootstrap.js to
reference a local copy of jquery.js isn't.

Possibly the confusion here is the name. This bootstrap.js has *nothing*
to do with a similar file from JQuery. It is a django-ajax-selects
file. I quoted the entire contents of it previously.

If we want this file to get served by Django its template system, we
would need to allocate some url to it within ajax_select/urls.py, and
move it to the Django template's directory. Not sure I could convince
upstream of the need for the extra complexity.

This is a file that needs to be loaded for every page, so there is the
extra load and roundtrip on the server to think about too, serving a
file through Django instead of serving a cachable file directly from
disk.


> Sounds like there needs to be some clarification here. What I'm
> expecting is something like this:
>
> 0: blah.js lives in the django-ajax-select VCS, upstream.
>
> 1: javascript.py is configured to convert that to a symlink to
> the .min.js from an external package or to uglify the VCS version into
> a .min.js and remove the .js from the django-ajax-select binary
> package. This happens at build time of django-ajax-select so that
> security fixes to blah.js can be applied as Debian patches to
> django-ajax-select with the assurance that changes to the .js do get
> carried into the .min.js that every dependency actually uses. If
> d-a-s does the uglify, then d-a-s is in sole control of where
> that .min.js can be found.

So if my understanding is correct, people who use the package directly
from PyPI will get blah.js, not the minified version?


> 2: Apps using django-ajax-select can call a templatetag (which lives
> in the d-a-s python code) to get the location of the .min.js installed
> by django-ajax-select (whether that's a symlink or not) or can be left
> to do their own setup of finding it. As a file installed by d-a-s, it's
> quite possible that apps which are packaged for Debian would simply put
> the installed location into their own configuration of javascript.py in
> their own source code. In that sense, d-a-s is no different to
> libjs-blah which puts a .min.js into /usr/share/ - apps can simply list
> that in their own configuration for javascript.py. If using a
> templatetag, the templatetag can be generic for the d-a-s location,
> independent of what {{ STATIC_URL }} says within the app using d-a-s.
> Any logic about whether to reference it or not either goes into the
> dependency app or the templatetag. Overall, it's simpler to just get
> dependencies to use their own javascript.py config.

Ok, so here is a fundemental difference in philosophy.

Upstream wants to have all of this included automagically without the
App having to do anything. This is done with the bootstrap.js file. The
bootstrap.js file is referenced by Django media objects from the
fields. This has the advantage that it will work with fields with the
Django admin interface without having to overload the admin/base.html
template file.

Maybe it would be better to require all Apps use a specified templatetag
at the top of their template files. That way we could completely delete
the bootstrap.js file.

I guess the key problem I see with this, from upstreams perspective, is
that this would require copying and overriding the
django/contrib/admin/templates/admin/base.html file to get this working
properly with Django admin.

Or another option would be to delete bootstrap.js and replace the media
object reference in fields.py with direct references to jquery.js
conditional on AJAX_SELECT_BOOTSTRAP being set to True - this would mean
the autodetection on jquery is gone however.

> setup.py isn't useful here - it barely knows how to do the install of
> the files in the first place, let alone actually implementing logic
> during the install.

setup.py is the only file executed however when non-Debian user's or
virtualenv user's install packages with pip install.
-- 
Brian May <bam@debian.org>