Preventing accidental overwriting has been on my todo list for many years. But since it's so very rare in practice I haven't gotten around to it.
Django forms having this problem is, in my opinion, WAY down the list of problems. I originally wrote the forms library in iommi to be able to programmatically create forms in a sane way but it has since evolved to fix many more of the weaknesses of django. Some highlights:
- good rendering of forms to html!
- that can be customized without resorting to writing gigantic amounts of brittle template code
- render form errors
- strip space from inputs by default
- always writes the encoding attr so file uploads work by default instead of silently failing by default
- you don't need to manually pass request.FILES (another silent failure not just beginners get bitten by)
- don't allow misses like duplicate names that causes silent data loss
Plus the iommi features of nesting and having multiple forms/tables/menus/etc on one page with clean composition.
I’m curious about how this scales. All my previous experiences with Django Channels, even since 1.0 to 2.0, have faced serious reliability issues and tricky bugs even in small apps.
Over recent weeks there have been a few HN posts relating to Django and how it interacts with "modern" ecosystems. Over Christmas I began working on a Django extension which would help leverage some features usually seen only in javascript-heavy websites, without the pain of writing custom code, in investing in browser-heavy automated tests.
The "killer" features I am hoping to bring to the Django community is the ability to have strong data consistency assurances between requests when editing data, as well as realtime server-driven validation of form inputs, alongside optional realtime "autosaving" of fields as changes are made. You can see how this looks here: https://user-images.githubusercontent.com/236562/153730557-a...
I have also attempted to minimise how much an existing codebase needs to be altered to use or test this. No database schema changes are required, and mostly it's just a matter of changing import statements from "django..." to "nango..."
This is very much a proof-of-concept at the moment and certainly not fit for production, and I welcome all suggestions and critiques. A quickstart script is included in the repo which should minimise the pain in running the code locally.