Conventions, not Rules

As many newcomers to Python discover, a lot of things they've lived with as rules in other languages [such as public/private members] ... and, conversely, some things they're accustomed to as conventions are now rules [like indenting].

Now, Django continues its history of embracing Pythonic ideals when it comes to filenames. Many frameworks are very strict about what goes where ... in almost all cases, Django couldn't care less.

Note: This post is still a Work In Progress. I am posting it now to help people with what I have, and seek feedback and further input.

Recently a few people have been asking about managing dynamic numbers of FormSets in Django.

When we look at how Admin handles inlines we see Django can handle this already.

So, 4 years ago [already??] I wrote a post about a shortcut to getting "User registration with verification email", using very little code by leveraging the password reset machinery built into Django.

Since then, of course, Django has moved on... and recently, the auth views were rewritten as class-based views, which changes the game entirely.

As a result, I've committed to providing here an updated version of the previous post.

Every so often (quite frequently, actually) you'll get someone in #django begging for help trying to integrate some app that promises the world ... at least, as far as it concerns user registration and profiles.

Update: A couple of people pointed out the original version would end up requiring the user to enter their email twice. I've now amended the code so the password_reset view's work is now done in the registration CreateView. This makes the view a little more complicated, but the URLs and user workflow much simpler.

The thing is, now that we have custom User models, doing this is easier than ever before - yes, even including email verification.

So, I saw a post recently about Build an API under 30 lines of code using Flask.

I started wondering what it would take to do the same in Django.

The two main tools we're going go use are JsonResponse and ModelForm.

This comes up a lot in #django ... and the solution is [as many are with Django] much simpler than people assume.

Frequently I see people reach for formsets, in the mistaken conclusion that formsets are for operating on related models. The sad part is that formsets rely on the same functionality that the proper solution relies on, but the seeker does not see it.

Somewhere people get the idea that for a single <form> submission, they can only use a single Form class... but the formset should show that that's not true; it uses multiple forms from the one submission.