Re: HttpResponse headers interface

[David Smith]

The recent change to `url()` was a good example of this; even though it was in 
a DEP and the docs for a long time it still caused a lot of noise when the 
deprecation path was finally started.

The projects (ok, small sample) I've looked at are only now making this change. 
Folks will only change their code when they absolutely need to.

Could a warning in a of 'hey, did you know there is a new way to do this and 
btw the current way is going away' be more helpful. (I suspect not, but putting 
it out here).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a21bac06-1f87-42ea-bc90-f6829cb131c6o%40googlegroups.com.

Re: Management of static assets

[David Smith]

Hi All,

Thank you all for your time taken to read and respond to this topic. 

Based on the conversation I'll try and summarise to try and gain wider 
approval. 

-  There is a valid use case for form media so it should not be deprecated
-  The name is wrong so we should proceed with the rename
-  There are some areas where the current feature can be improved and we 
should progress with these (some items noted on this thread + other open 
tickets on trac)
-  If we wish to 'do more' it requires much more thought and a DEP. A DEP 
should most likely focus on building blocks rather than a full solution. 

The key thing here in the short term is the name change. If there are no 
objections to this I am happy to look at an implementation. Could then come 
back to the mailing list before it's merged, especially as it will be a 
breaking change?

Kind Regards

David



On Saturday, 9 May 2020 21:39:51 UTC+1, Aymeric Augustin wrote:
>
> Thanks David for investigating the topic thoroughly! I wasn't expecting 
> all that when I filed a one-line ticket six years ago :-) So, here's a 
> bunch of opinions.
>
>
> Before I start, I'd like to quote the intro to the Media class 
> :
>
> *Rendering an attractive and easy-to-use Web form requires more than just 
> HTML - it also requires CSS stylesheets, and if you want to use fancy 
> « Web2.0 » widgets, you may also need to include some JavaScript on each 
> page. The exact combination of CSS and JavaScript that is required for any 
> given page will depend upon the widgets that are in use on that page.*
>
>
> That was the reasonable thing to do before single-page apps, asset 
> pipelines, bundlers and code splitting. It's still a fairly reasonable 
> thing to do on a website that relies on good old HTML forms but would 
> benefit from "*fancy « Web2.0 » widgets".*
>
>
> *1. Django shouldn't do anything* (besides what 
> django.contrib.staticfiles already does)* for projects that use webpack *(or 
> any other bundler)
>
> The correct approach with a bundler is to bundle all JavaScript code and, 
> if needed, to optimize with code splitting. Attempting to include only 
> what's needed on each page, like Media does, will usually be 
> counterproductive, because it will general different bundle for different 
> pages and defeat caching by the browser.
>
> Then I know two techniques for integrating the frontend code with Django:
>
> - the single page app 
> 
>  (website 
> and API on separate domains) — this is clearly out of scope of this 
> discussion as Django only provides an API in this scenario
> - what I call the hybrid app 
> 
>  (website 
> and API on the same domain) — here django.contrib.staticfiles helps; it 
> comes after the JavaScript bundler in the deployment pipeline (and I prefer 
> plain django.contrib.staticfiles over django-webpack-loader, but that's 
> another story)
>
> (NB: while the blog posts I just linked to focus on create-react-app, the 
> concepts apply to any modern JavaScript toolchain.)
>
> Regardless, Django already provides more than we need. For example, both 
> webpack and django.contrib.staticfiles add hashes to file names to ensure 
> cache invalidation.
>
> So my answer to questions 3, 4 and 5 is "no, except maybe documentation".
>
> Now, let's leave this brave new world and remember the jQuery era.
>
>
> *2. Media makes sense*
>
> Although pluggable apps are fantastic, the concept doesn't work well for 
> templates, which is where  and 

Re: calling self.errors in a form in a formset breaks deletion

[David Smith]

Hi Carles,

Hope you are well.

You mentioned you are using crispy-forms. :-)

Have you seen this part of the docs, it allows you to update forms 'on the go'.

I've not really played with this but it sounds similar to what you need?

https://django-crispy-forms.readthedocs.io/en/latest/dynamic_layouts.html

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/41289ee1-6c5b-4699-bc15-cec57322af7fo%40googlegroups.com.

Management of static assets

[David Smith]

Hi All, 

I hope you are all well. 

I've been thinking about static assets over the past week or so following 
my email on widget media. I collated the past 6 year's worth of discussions 
into a single source, with relevant extracts and links to sources. I've 
also set out some options and given my thoughts (FWIW). I've not yet done 
any detailed planning as I think we need to agree general principles first. 
Sorry this is a bit long, may need to go get a cup of tea first :-)

I hope this is helpful to aid discussion on this topic 🤞 



*Summary*
The below sets out this historical context for ticket #22298 
 (What to do with Widget 
Media) and the wider discussions this generated on how Django should manage 
assets. Whilst there are some detailed points below, these are to help set 
context and to aid discussion. This is a wide and deep topic and therefore 
I suggest at this stage we discuss the topic with an aim to agree the 
overall direction. The principle I suggest we discuss is:

*In alignment with it's "batteries included" philosophy, should Django have 
an aim to improve the management of static assets? *

In addition to seeking agreement to this broad principle I'd also like to 
encourage discussion on the topics which fall under this category. Here are 
some questions to aid a discussion, although I fully expect the 
conversation to be wider than these initial suggestions. Some items may be 
easier to seek agreement on than others; however, all will take time and 
effort of the community to agree the correct design and implementation. 

1. Should Django have an improved way of managing assets within apps 
(something akin to #29586)
2. Should Django have the ability to compile and compress assets?
3. Should Django have Webpack support?
4. Should Django have improved support for JS frameworks?
5. Should Django have support for NPM?

Based on evidence below my view is that there is enough support to improve 
Django's support in this area generally. Assuming this is agreed I think 
the a range of options are:

   - Provide improve awareness of static assets with Django core to help 
   3rd party packages
   - In addition, integrate an asset pipeline
   - In addition, integration with webpack, and support JS frameworks.


My personal view is that option one is fairly cautious, there are already 
3rd party packages which enable this functionality, and that the third one 
is too ambitious. I suspect most people using JS frameworks are doing it 
anyway irrespective of what is part of Django code. I think there the most 
value can be added is for sites with mostly HTML / CSS and, but would like 
some help compiling CSS and "sprinkling" a bit of JS here and there. 

I'd therefore suggest we start by revisiting work previously done by Claude 
to understand if this is the right foundation. Once this is complete this 
will enable phase two to integrate an asset pipeline / compressor into 
Django. I would suggest that this is via a separate package to start with 
under the Django umbrella. I suspect the pace of iteration will be too fast 
for Django core, and we would like it to be more stable before merging it. 
Would it be possible to use some of the existing work that the wider 
community has already developed and explore building on (or 'just' use) an 
existing 3rd party package? (I don't know how acceptable this is, or not)

My personal recommendation is also that ticket #22298 is closed or marked 
as someday / maybe. Widget Media may be useful in the future, we don't know 
yet. I would not support the deprecation of this functionality without  
something better to replace it. I also feel that a rename would have little 
benefit but would cause disruption for those using it and numbers may be 
high given it's been in place for many years. If agreement can be sought on 
this then it will help other Media related tickets to be progressed 
(example : #21987).

Below is an overview of various comments, on tickets, mailing list and pull 
requests over the past 6 years. 

*The ticket in question was on Widget Media, So what does Widget Media do?*

It is used to load CSS or JS to widgets / forms (e.g. add 

Re: Widget Media Class

[David Smith]

Hi Carlton,

Thank you for the response. I really appreciate your continued support / 
guidance. 

Sorry, for asking the question in that way, eventually I'll learn 'how things 
are done round here' :-)

I'll go and investigate in more detail.

David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5348baab-5956-433c-8dc0-825832f40840%40googlegroups.com.

Widget Media Class

[David Smith]

Hi all,

Hope you are all well.

Ticket #22298  discusses what 
to do with the Media class for widgets. Discussion on the ticket dates back 
to 2014, are wide ranging and a conclusion has not been reached. 

Now that time has moved on somewhat what are the current opinions on this 
ticket? 

Looking forward to hearing your views.


David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0b2ad98e-31a1-4f6c-b71d-39f3f3293e6f%40googlegroups.com.

GSoC Mentors

[David Smith]

Hi Carlton,

I'm happy to help out with 1), if you think I would be helpful. 

I will not be of much help with 2) :-) 

David

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/da593286-005f-4a1a-8359-cf8210a1a975%40googlegroups.com.