Form assets and static file storage

[Dominic Rodger]

I recently came across a problem when using ManifestStaticFilesStorage on an app with form media, which the documentation doesn't seem to address. I'm posting here rather that on django-users, since I think we ought to at least document how to fix it, or preferably come up with a better way of solving it.

The app I was using is django-image-cropping, which specifies the media for a widget like this (see image_cropping/widgets.py#L60):

    def _media(self):

        js = [

            "image_cropping/js/jquery.Jcrop.min.js",

            "image_cropping/image_cropping.js",

        ]

        css = {'all': ("image_cropping/css/jquery.Jcrop.min.css",

                       "image_cropping/css/image_cropping.css",)}

        return forms.Media(css=css, js=js)

    media = property(_media)

When rendered to HTML, it generates a static path (i.e. STATIC_URL is prepended), but doesn't correctly generate paths to minified content, so you get 404s. django.contrib.admin has worked around this - by using the admin_static template tag (see django/contrib/admin/templatetags/admin_static.py#L10). I fixed up django-image-cropping by porting that workaround to the app itself (see PR), but it feels like it might be worth documenting how people should be handling this in their apps. I'm thinking of something along the lines of making the code in admin_static.py less admin specific (so far as I can see, it doesn't actually have anything to do with django.contrib.admin) - perhaps exposing the functionality in django.utils, and then having the templatetag admin_static use that function.

If I've missed something, my apologies, but I couldn't find any tickets related to this. It seems like something others would have come across already, so again, apologies if there's already a ticket for this, or if I've gone about this in a braindead way.

If patches/tickets need writing, I'd be happy to get stuck in - just wanted some clarity that I'm not crazy first :)

Dom

[Collin Anderson]

Hi Dom,

Yeah, it looks like the admin_static is simply uses the staticfiles tag if staticfiles is installed, otherwise falls back to the core static? The only reason why it admin_static exists is because the admin can't rely on staticfiles being installed, right? Maybe pulling the the staticfiles tag into builtins would help?

Collin

[Tim Graham]

The problem has come up before:
https://code.djangoproject.com/ticket/18455

but there is some question about whether the design of the Media class is something we should try to continue building on:
https://code.djangoproject.com/ticket/22298

The suggestion to have the built-in static tag work like admin_static does seem like a practical one. The question is whether practicality beats purity (keeping contrib dependencies, albeit a conditional one in this case, out of core) in this case. I'd say yes, unless there's a suitable alternate proposal to address the problem.

[Carl Meyer]

On 06/10/2015 07:52 AM, Tim Graham wrote:
> The problem has come up before:
> https://code.djangoproject.com/ticket/18455
>
> but there is some question about whether the design of the Media class
> is something we should try to continue building on:
> https://code.djangoproject.com/ticket/22298
>
> The suggestion to have the built-in static tag work like admin_static
> does seem like a practical one. The question is whether practicality
> beats purity (keeping contrib dependencies, albeit a conditional one in
> this case, out of core) in this case. I'd say yes, unless there's a
> suitable alternate proposal to address the problem.

It seems like there's some confusion here between form Media and the
'static' template tag; the two do similar things, but are separate. This
report, and #18455, are about form Media, which means having
staticfiles' "static" tag in core builtin tags wouldn't even help. The
problematic code is in Media.absolute_path() method, in
django/forms/widgets.py; template tags are not involved.

I think Jannis' suggestion in #18455 (that there should be a
staticfiles-specific subclass of Media that uses the storage URL) is the
right one, presuming we even want to continue recommending the Media
approach at all. The questions raised about that in #22298 are good
ones. Personally I don't ever use Media, due to the performance effects
of loading lots of little JS files. This gets into the question of
Django's support for "front-end components" that was recently discussed
in another thread.

Carl