App static files (#29586)

Claude Paroz

unread,

Jul 23, 2018, 11:36:05 AM7/23/18

to django-d...@googlegroups.com

Hi,

I just created a new feature request [1] to be able to define static
files per application, including a POC patch [2].

[1] https://code.djangoproject.com/ticket/29586
[2] https://github.com/django/django/pull/10218

Feel free to discuss it here for general discussion on the feature
utility, or comment on the ticket or on the pull request for
implementation details.

Cheers,

Claude
--
www.2xlibre.net

Florian Apolloner

unread,

Jul 23, 2018, 12:12:32 PM7/23/18

to Django developers (Contributions to Django itself)

Hi Claude,

a few things after a quick glance at it. Overall the feature seems rather simple and I do not see any reason why this would have to be in core from the start; ie it could easily evolve as a 3rd party app.

I am not that much into frontend dev, but from my experience a few things popped up rather quickly:

* I generally do not load all js/css in bulk, but rather only the essential stuff in <head> and the rest before the <body> ends. (or even just selecting files by type; css vs js etc…)

* The app level seems to be a rather coarse grained separation, I could imagine people wanting more control over it without generating more apps for separation.

* How would support for subressource integrity etc look like; integration with the storage system would be interesting here

* Any thoughts on asset pipelines?

Cheers,

Florian

Michael Manfre

unread,

Jul 23, 2018, 12:41:48 PM7/23/18

to django-d...@googlegroups.com

On Mon, Jul 23, 2018 at 12:12 PM Florian Apolloner <f.apo...@gmail.com> wrote:

* Any thoughts on asset pipelines?

This seems like it would be critical functionality. It might also help users to avoid potential asset ordering issues without needing to create more apps to resolve conflicts.

Regards,

Michael Manfre

Claude Paroz

unread,

Jul 23, 2018, 2:14:23 PM7/23/18

to Django developers (Contributions to Django itself)

Le lundi 23 juillet 2018 18:12:32 UTC+2, Florian Apolloner a écrit :

Hi Claude,

a few things after a quick glance at it. Overall the feature seems rather simple and I do not see any reason why this would have to be in core from the start; ie it could easily evolve as a 3rd party app.

I purposely kept minimal functionality to start with. The idea is to have a minimal common structure in core, so as 3rd party apps can build upon that minimal structure and add more functionality. e.g. more Asset subclasses can be created to customize behavior.

I am not that much into frontend dev, but from my experience a few things popped up rather quickly:

* I generally do not load all js/css in bulk, but rather only the essential stuff in <head> and the rest before the <body> ends. (or even just selecting files by type; css vs js etc…)

I think that once you have an asset list, you can program the logic specific to your application. The site_static template tag could be considered mainly as an implementation example.

* The app level seems to be a rather coarse grained separation, I could imagine people wanting more control over it without generating more apps for separation.

Once again, one can program a more specific logic by Asset subclasses in the app config assets. A JS() subclass could accept a 'section' parameter which could then be used to segment asset rendering.

* How would support for subressource integrity etc look like; integration with the storage system would be interesting here

I think this is typically something that should be trivial to implement after this patch is in core. It might be as simple as adding an appropriate kwarg to the Asset() class.

* Any thoughts on asset pipelines?

Sure, the idea is to put a base structure in place to support such functionalities at a later stage (in core or as 3rd party like django-compressor).

Thanks for your input!

Florian Apolloner

unread,

Jul 23, 2018, 2:32:55 PM7/23/18

to Django developers (Contributions to Django itself)

Hi Claude,

On Monday, July 23, 2018 at 8:14:23 PM UTC+2, Claude Paroz wrote:

Sure, the idea is to put a base structure in place to support such functionalities at a later stage (in core or as 3rd party like django-compressor).

I am just a little bit worried about adding this without any concrete plan on how 3rd party apps are going to use it. What speaks against trying this outside of core like channels? (I'll happily put it under the django umbrella, but core seems a little bit fast tracked to me).

Cheers,

Florian

Claude Paroz

unread,

Jul 23, 2018, 3:17:24 PM7/23/18

to Django developers (Contributions to Django itself)

I think that such little code doesn't make much sense as a 3rd party app. Either we consider it a common base to build upon by 3rd parties or we conclude that it isn't worth to have such a base.
One of the goal of this thread is to hear from potential users of this proposed API.
I'll see if I can add subresource integrity support to demonstrate a potential added value.

Claude

Claude Paroz

unread,

Jul 23, 2018, 4:22:33 PM7/23/18

to Django developers (Contributions to Django itself)

Le lundi 23 juillet 2018 21:17:24 UTC+2, Claude Paroz a écrit :

I'll see if I can add subresource integrity support to demonstrate a potential added value.

Just for feasibility's sake, here's a quick (and probably dirty) way to implement subresource integrity based on the new code.

https://github.com/claudep/django/commit/cba848c3590949e78861ce95c3cc466456c15870

Claude

Carlton Gibson

unread,

Feb 4, 2019, 4:47:29 AM2/4/19

to Django developers (Contributions to Django itself)

Hi Claude.

Is this something you're still interested in?

Do you think it might make a good GSoC project?

C.

Claude Paroz

unread,

Feb 4, 2019, 7:47:42 AM2/4/19

to Django developers (Contributions to Django itself)

Hi Carlton,

I'm currently in "pause mode" for Django master. I didn't receive any input until now with my proposal.

I think Django would benefit of such a development, not necessarily with my suggested approach, but something similar.

As for GSoC, it's difficult to say. I'm always concerned by the "single-person" nature of GSoCs, especially when the development direction is not clear like here.

Claude

Reply all

Reply to author

Forward