Re: DEP Pre-posal: Re-Designing Django Forms

[Dmitriy Sintsov]

Hi.

Client-side implementation of fields visual behavior and their validation 
should be hooked up via document.ready custom JS scripts via form ID or 
form class. There is no universal solution for that.

When using pure client-side forms from npm, it is possible to map these to 
Django models via DRF, however there will be no custom server-side widgets 
then. To me one of the most important parts of Django Forms is the ability 
to develop your own custom widgets.

Server-side validation of forms can be processed with AJAX, there are few 
implementations of that, including mine:
https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/docs/forms.rst#ajax-forms-processing

It saves quite enough ot HTTP traffic, because instead of complete 
re-rendering of submitted form HTML page, only the list of field ID's and 
their error messages are returned to be highlighed by client-side 
Javascript code.
It also allows to submit forms in AJAX "popup-like" dialogs:
https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/db4beeb18296c87af8626980b6a0c91e16f80863/django_jinja_knockout/views/ajax.py#L203

It supports file upload progress bar automatically as well:
https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/db4beeb18296c87af8626980b6a0c91e16f80863/django_jinja_knockout/static/djk/js/app.js#L1568

It's not so flexible (tied to Bootstrap 3 via Jinja2 macros) but it's 
possible to generalize such approach.

With client-side Javascript there is always the trouble which library to 
chose - Angular / Vue / React - cannot suit everyone. I use Knockout.js 
which is outdated but requires no webpack / npm and works with ES5. It is 
also fully compatible to server-side DTL / Jinja2 templates (it does not 
use double curly braces, thus causes no syntax clashes).

Dmitriy
On Wednesday, January 31, 2018 at 6:31:56 PM UTC+3, Robert Roskam wrote:
>
> Hey All,
>
> Something I've regularly run into as a challenge is the implementation of 
> Django forms work well in the simple use cases, but as the use case grows 
> in complexity, Django forms become more difficult to work with.
>
> I know that's a super general statement, but here's the simplest complex 
> example I can give you. Lets say you're making an application for a home 
> builder, so that their Project Managers can better coordinate the builds. 
> One of the features is the ability to take notes and pictures on anything 
> that's not yet done and specifically if it relates to a specific piece of 
> equipment (AC, furnace, water pump, etc), they can add that too. Below is a 
> moderately simplistic example:
>
> class Note(models.Model):
> project = models.ForeignKey('project_management.Project', 
> related_name="notes")
> equipment = models.ForeignKey('equipment.Equipment', null=True, 
> blank=True, related_name="notes")
> picture = models.FileField(null=True, blank=True)
> is_blocker = models.BooleanField(default=True)
> comment = models.TextField()
> created_by = models.ForeignKey('users.User', verbose_name="Created By")
> created_date = models.DateTimeField(default=timezone.now, 
> verbose_name="Created Date")
>
>
> class NoteModalForm(forms.ModelForm):
> class Meta:
> fields = ('comment', 'is_blocker','equipment', 'picture')
> model = Note
> labels = {
> 'comment': 'Note',
> 'is_blocker': 'Blocking Issue',
> 'picture': 'Picture',
> }
> widgets = {
> 'picture': DragNDropFileButtonInput(button_text='Select file 
> to Upload',
> button_classes='btn 
> btn-bordered uploader'),
> }
>
>
>
> General comments first: 
>
>1. I would say there's no better way to accomplish what is currently 
>on that form given the current Form Meta API. (Willing to be challenged on 
>this point, btw.)
>2. The repetition of picture 3 times over (fields tuple, labels dict, 
>widgets, dict) seems to be inherently not DRY. If this gets very long, 
> then 
>it becomes harder to manage.
>3. The API on the Model Form itself behaves not quite like you'd 
>expect initially. You'd expect redeclaring fields directly on a form for 
> it 
>to function like a dictionary update, if the value doesn't exist in the 
>incoming dictionary, it keeps what's there. It actually behaves like 
>re-declaration. This very significant behavior is buried in a note (
>
> https://docs.djangoproject.com/en/2.0/topics/forms/modelforms/#overriding-the-default-fields).
>  
>Additionally, you'll have sources like pydanny basically tell you this is 
>an anti-pattern: https://www.pydanny.com/overloading-form-fields.html
>4. The API on Meta leads you to believe initially that you can 
>override lots of things via Meta, and it's difficult to discover what is 
> or 
>is not supported. (I usually dig into django.forms.models, and then wander 
>around until I get 

Re: Adding a tutorial for Channels

[Robert Roskam]

+1

On Monday, February 5, 2018 at 7:05:11 AM UTC-5, David Foster wrote:
>
> This weekend I spent several hours getting Channels configured to run a 
> simple chat server . 
> This was an experiment I wanted to do before trying to integrate Channels 
> into a much larger project.
>
> It would have taken me a lot less time if there had been a tutorial in the 
> official 
> Channels docs  similar 
> in style to the Django tutorial 
>  that showed how 
> to configure Channels and use it to work with WebSockets while also 
> touching on the important Channels concepts and linking to reference 
> documentation where appropriate. So I'd like to offer to write such a 
> tutorial.
>
> Would this be a welcome contribution?
>
> - 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3494fc07-d40c-4b54-abb6-118db758bd35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP Pre-posal: Re-Designing Django Forms

[Robert Roskam]

Hey Tom,

My main goal is to improve the Django Form API interface for writing Python 
code for what Django has historically done: server-side rendered web pages. 
So any client-validation hooks I might provide would not be fully 
implemented integrations rather a more convenient integration. (I'm 
thinking of things like Parsley.js here.)

If I can happen to improve the API for interfacing with JS frameworks, then 
I'll be happy to do so, but that's honestly not even secondary in 
importance to me. However, my experience so far as been they assume a REST 
API on the backend and otherwise want to be in charge of the DOM inside 
them.

Robert Roskam

On Monday, February 5, 2018 at 5:26:25 PM UTC-5, Tom Forbes wrote:
>
> > Perhaps we should just be able to swap Forms with WTForms or another 
> python library and bake in ElementUI,
>
> There are a plethora of UI frameworks with different tradeoffs, I really 
> don't think Django sound pick one.
>
> However a stronger integration with the JS-build tools of the day like 
> Yarn, webpack et al would be a good step in the right direction, and more 
> agnostic than just 'use this UI framework we picked for you'.
>
> > perhaps it's time for npm to become a first class citizen.
>
> I think if Django is going to stay relevant to building most/all kinds of 
> web apps this is something that will need to happen. To be fair, npm and 
> the whole frontend ecosystem has only really 'matured' in the last couple 
> of years, it's come a long way since Django started.
>
> On 4 Feb 2018 00:36, "Jamesie Pic"  
> wrote:
>
> On Thu, Feb 1, 2018 at 12:46 PM, Marc Tamlyn  > wrote:
> > This is a huge project to achieve everything you mentioned in your 
> email, and it has implications across a large number of Django packages 
> (not least the admin). I don't want to discourage you, but don't 
> underestimate how much work it would be to get a good replacement for forms 
> for the modern web.
>
> Perhaps we should just be able to swap Forms with WTForms or another 
> python library and bake in ElementUI, even if that means replacing 
> template_name with vue_name in the view generic class, but if we're talking 
> about "modern web" then perhaps it's time for npm to become a first class 
> citizen.
>
> > Your next steps should be to research, spec and potentially write a DEP.
>
> In my recent research it seemed ElementUI the most feature complete UI. It 
> includes ajax file upload which every user expects in the modern web which 
> seems to be the feature which defines feature-completion of a UI framework, 
> compared to what HTML offers out of the box.
>
> Thanks a lot for doing something about this Robert, forms in django 
> definitely needs a major refactoring sprint, typically remove the 
> field/widget layer and rely on one level inheritance that will help a lot 
> for example with material design which displays field.name inside the 
> widget, not possible with current object design.
>
> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAC6Op1_ESqUA6tUwQxwgastH4XzQ%3D-PBybtq__2yWEuc0OH4BA%40mail.gmail.com
>  
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2213a3ba-a4e3-4e3c-b022-f81c01ce3c9c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a tutorial for Channels

[Tomiwa Ademidun]

Thank you, I would also really appreciate it. If you could also include a 
section on deploying a channels project (e.g. to Heroku ) and how to do 
background tasks (e.g. similar to celery) I would appreciate that as well.

On Monday, February 5, 2018 at 7:05:11 AM UTC-5, David Foster wrote:
>
> This weekend I spent several hours getting Channels configured to run a 
> simple chat server . 
> This was an experiment I wanted to do before trying to integrate Channels 
> into a much larger project.
>
> It would have taken me a lot less time if there had been a tutorial in the 
> official 
> Channels docs  similar 
> in style to the Django tutorial 
>  that showed how 
> to configure Channels and use it to work with WebSockets while also 
> touching on the important Channels concepts and linking to reference 
> documentation where appropriate. So I'd like to offer to write such a 
> tutorial.
>
> Would this be a welcome contribution?
>
> - 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/51f7b8cc-2379-411c-9e01-f04f7cd50136%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEP Pre-posal: Re-Designing Django Forms

[Tom Forbes]

> Perhaps we should just be able to swap Forms with WTForms or another
python library and bake in ElementUI,

There are a plethora of UI frameworks with different tradeoffs, I really
don't think Django sound pick one.

However a stronger integration with the JS-build tools of the day like
Yarn, webpack et al would be a good step in the right direction, and more
agnostic than just 'use this UI framework we picked for you'.

> perhaps it's time for npm to become a first class citizen.

I think if Django is going to stay relevant to building most/all kinds of
web apps this is something that will need to happen. To be fair, npm and
the whole frontend ecosystem has only really 'matured' in the last couple
of years, it's come a long way since Django started.

On 4 Feb 2018 00:36, "Jamesie Pic"  wrote:

On Thu, Feb 1, 2018 at 12:46 PM, Marc Tamlyn  wrote:
> This is a huge project to achieve everything you mentioned in your email,
and it has implications across a large number of Django packages (not least
the admin). I don't want to discourage you, but don't underestimate how
much work it would be to get a good replacement for forms for the modern
web.

Perhaps we should just be able to swap Forms with WTForms or another python
library and bake in ElementUI, even if that means replacing template_name
with vue_name in the view generic class, but if we're talking about "modern
web" then perhaps it's time for npm to become a first class citizen.

> Your next steps should be to research, spec and potentially write a DEP.

In my recent research it seemed ElementUI the most feature complete UI. It
includes ajax file upload which every user expects in the modern web which
seems to be the feature which defines feature-completion of a UI framework,
compared to what HTML offers out of the box.

Thanks a lot for doing something about this Robert, forms in django
definitely needs a major refactoring sprint, typically remove the
field/widget layer and rely on one level inheritance that will help a lot
for example with material design which displays field.name inside the
widget, not possible with current object design.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/
msgid/django-developers/CAC6Op1_ESqUA6tUwQxwgastH4XzQ%
3D-PBybtq__2yWEuc0OH4BA%40mail.gmail.com

.

For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFNZOJOJE4me_7nw0K3_hpXWN_vzsCAip_OvgmuLHABmuFgDvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a tutorial for Channels

[Andrew Godwin]

I would very much welcome a narrative tutorial like the Django docs - I did
not have the time to personally write and QA one before the 2.0 release,
unfortunately. I'm happy to help out if you want to email me personally to
discuss!

Andrew

On Sun, Feb 4, 2018 at 10:39 PM, David Foster  wrote:

> This weekend I spent several hours getting Channels configured to run a
> simple chat server .
> This was an experiment I wanted to do before trying to integrate Channels
> into a much larger project.
>
> It would have taken me a lot less time if there had been a tutorial in the 
> official
> Channels docs  similar
> in style to the Django tutorial
>  that showed how
> to configure Channels and use it to work with WebSockets while also
> touching on the important Channels concepts and linking to reference
> documentation where appropriate. So I'd like to offer to write such a
> tutorial.
>
> Would this be a welcome contribution?
>
> - 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/9b68e3cf-76de-4506-9733-
> 00b2d640b1e2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1upcygqRNkzKmcWXnrxJVm5yR--FB8%2BctqZAmHVee5T0tQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jinja2 form rendering for the admin

[Tim Graham]

I guess it's fine. I see you already created a ticket: 
https://code.djangoproject.com/ticket/29115.

On Friday, February 2, 2018 at 3:17:45 PM UTC-5, Joey Wilhelm wrote:
>
> I know that Jinja2 vs DTL rendering can be a contentious issue at times, 
> so I want to start from the outset saying that I am not proposing 
> re-implementing the entire admin in Jinja2 templates!
>
> However, that said, I believe that it is not only possible, but in fact 
> easy, to get forms to render using the Jinja2 engine in the admin. I've 
> actually just managed this on my current project at work, and I wanted to 
> see what thoughts would be for inclusion in core.
>
> According to the documentation[1], "...django.contrib.admin doesn’t 
> include Jinja2 templates for its widgets due to their usage of Django 
> template tags."
>
> After some digging, though, it appears that the "spaceless" tag is the 
> only one in use which is not readily available in Jinja2. And this is only 
> used 
> in django/contrib/admin/templates/admin/widgets/related_widget_wrapper.html.
>
> So I was able to reimplement this template in Jinja2, minus the spaceless 
> tag, and I was off to the races. On a few admin pages with large numbers of 
> inlines, the load time was cut in half or better.
>
> But, of course, there was one more small catch. I had to use the 
> "TemplateSetting" form renderer rather than the "Jinja2" form renderer, 
> because I had no way to alter the Jinja2 environment for the form renderer. 
> The environment I refer to in my settings, however, is pulled almost 
> verbatim from the documentation for the Jinja2 backend[2]. I only had to 
> add one thing: i18n. Which turns out to be fairly simple to do with Jinja2 
> + Django. I was even able to use the "gettext" and "ngettext" from 
> django.utils.translation.
>
> So what I'm proposing here boils down to a few pieces:
>
> 1) Create jinja2 templates for the admin widgets. I already have one of 
> these done, and the others look like it may be possible to simply copy them.
> 2) Document how to add i18n to the Jinja2 environment
> 3) Perhaps provide a default environment to Jinja2, providing both static 
> and url, as currently documented in the example Jinja2 environment, along 
> with i18n. This would provide a better out-of-the-box experience for users, 
> including being able to set the FORM_RENDERER to Jinja2, and have the admin 
> Just Work.
>
> So, thoughts? Is this something worth filing a ticket for?
>
> -Joey Wilhelm
>
> [1]: https://docs.djangoproject.com/en/2.0/ref/forms/renderers/#jinja2
> [2]: 
> https://docs.djangoproject.com/en/2.0/topics/templates/#django.template.backends.jinja2.Jinja2
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0bef1e63-f768-437a-a061-87e9c1f63091%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: DEP Pre-posal: Re-Designing Django Forms

[Matthew Pava]

> It includes ajax file upload which every user expects in the modern web which 
> seems to be the feature which defines feature-completion of a UI framework, 
> compared to what HTML offers out of the box.
Bandwagon logical fallacy (“every user expects”)

In my project, I have no need for file upload.  And I have no need for it in 
the foreseeable future, and, as such, I do not expect my framework to be able 
to handle it.

I’m neither supportive nor opposed to the idea of changing Django forms, but 
please avoid logical fallacies in supporting your position.


From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Jamesie Pic
Sent: Saturday, February 3, 2018 6:36 PM
To: django-developers@googlegroups.com
Subject: Re: DEP Pre-posal: Re-Designing Django Forms

On Thu, Feb 1, 2018 at 12:46 PM, Marc Tamlyn 
> wrote:
> This is a huge project to achieve everything you mentioned in your email, and 
> it has implications across a large number of Django packages (not least the 
> admin). I don't want to discourage you, but don't underestimate how much work 
> it would be to get a good replacement for forms for the modern web.

Perhaps we should just be able to swap Forms with WTForms or another python 
library and bake in ElementUI, even if that means replacing template_name with 
vue_name in the view generic class, but if we're talking about "modern web" 
then perhaps it's time for npm to become a first class citizen.

> Your next steps should be to research, spec and potentially write a DEP.

In my recent research it seemed ElementUI the most feature complete UI. It 
includes ajax file upload which every user expects in the modern web which 
seems to be the feature which defines feature-completion of a UI framework, 
compared to what HTML offers out of the box.

Thanks a lot for doing something about this Robert, forms in django definitely 
needs a major refactoring sprint, typically remove the field/widget layer and 
rely on one level inheritance that will help a lot for example with material 
design which displays field.name inside the widget, not 
possible with current object design.
--
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 post to this group, send email to 
django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_ESqUA6tUwQxwgastH4XzQ%3D-PBybtq__2yWEuc0OH4BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c44115b589e94fa0b6da27854b114332%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

Re: Adding a tutorial for Channels

[Michael Manfre]

Any improvements to documentation are greatly appreciated. Thank you for
taking the initiative.

Regards,
Michael Manfre

On Mon, Feb 5, 2018, 7:05 AM David Foster  wrote:

> This weekend I spent several hours getting Channels configured to run a
> simple chat server .
> This was an experiment I wanted to do before trying to integrate Channels
> into a much larger project.
>
> It would have taken me a lot less time if there had been a tutorial in the 
> official
> Channels docs  similar
> in style to the Django tutorial
>  that showed how
> to configure Channels and use it to work with WebSockets while also
> touching on the important Channels concepts and linking to reference
> documentation where appropriate. So I'd like to offer to write such a
> tutorial.
>
> Would this be a welcome contribution?
>
> - 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9b68e3cf-76de-4506-9733-00b2d640b1e2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAGdCwBurZDpM1nqRXECpiUsNH-4dEuejoL3S9OANg5qdYTckrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Adding a tutorial for Channels

[David Foster]

This weekend I spent several hours getting Channels configured to run a 
simple chat server . 
This was an experiment I wanted to do before trying to integrate Channels 
into a much larger project.

It would have taken me a lot less time if there had been a tutorial in the 
official 
Channels docs  similar 
in style to the Django tutorial 
 that showed how 
to configure Channels and use it to work with WebSockets while also 
touching on the important Channels concepts and linking to reference 
documentation where appropriate. So I'd like to offer to write such a 
tutorial.

Would this be a welcome contribution?

- 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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9b68e3cf-76de-4506-9733-00b2d640b1e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report -- February 5, 2018

[Carlton Gibson]

Hi all, 

Last week I reviewed patches on

https://code.djangoproject.com/ticket/29076 -- Changed .refresh_from_db() 
to clear cached relationships.
https://code.djangoproject.com/ticket/29036 -- Changed SelectDateWidget's 
empty value
https://code.djangoproject.com/ticket/29082 -- Make the test client 
automatically encode JSON data
https://github.com/django/django/pull/9649  -- Fixed imports per isort 
4.3.0.
https://code.djangoproject.com/ticket/28835 -- Made development server 
shutdown on SIGTERM
https://code.djangoproject.com/ticket/27795 -- Audit force_text invocations
https://github.com/django/django/pull/9648
https://github.com/django/django/pull/9652
https://code.djangoproject.com/ticket/25718 -- Allowed using None as a 
JSONField lookup value.
https://github.com/django/django/pull/9651  -- Simplified aggregation.tests.
https://code.djangoproject.com/ticket/29059 -- Made 
ChoiceWidget.optgroups() group non-grouped choices in null group.
https://code.djangoproject.com/ticket/27999 -- Add test Client support for 
HTTP 307 and 308 redirects
https://code.djangoproject.com/ticket/27398 -- Make 
SimpleTestCase.assertRedirects() URL comparison ignore ordering of query 
parameters

Kind Regards,

Carlton

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9716cab5-ea4a-44d3-8224-e8e9386f2398%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.