@Tom
> I'd be surprised if they didn't end up with the model default. Personally
I'd treat that as a regression, and revert to the older behavior.
I think Tim is saying the opposite, that Django 1.10 accidentally
introduced "fields missing from POST are set to model defaults" behavior.
@Tim
> I could imagine an API call where it would be useful for the model to use
the default if a user doesn't submit any data for that field
I think that the way to allow a key to be left out of POST entirely is
either:
1. Create a dict with defaults, then update it to the values in POST,
using the result to instantiate the form
2. Remove the field from the form (this could even be dynamic with
modelform_factory based on keys missing from POST)
In a web page, # 1 is basically what's happening, but the updating is
taking place in the UI.
For other cases (e.g., an API), a form method to get the same data used to
populate the HTML form values would be very helpful:
>>> class Egg(Model):
>>> temperature = Charfield(max_length=255, default='over medium')
>>> EggForm = modelform_factory(Egg, exclude=())
>>> form = EggForm()
>>> form.initial # This is only going to output the value given as
`initial`
{}
>>> form.proposed_new_property # <--- This lil guy right here
{'temperature': 'over medium'}
That would of course be helpful in creating an initial dict for my # 1 case
above.
>>> data = form.proposed_new_property
>>> data.update(request.POST)
>>> form = EggForm(data)
>>> form.is_valid()
>>> form.save()
I realize the form is now being instantiated twice, but it's necessary
because of kwargs like `initial`, and it's no different than the current
load-form-in-GET --> validate-form-in-POST workflow.
Thoughts?
On Friday, August 12, 2016 at 10:41:21 AM UTC-4, Tom Christie wrote:
>
> For the case of fields that haven't been included in the form POST, I'd be
> surprised if they didn't end up with the model default.
> Personally I'd treat that as a regression, and revert to the older
> behavior.
> Agree that the checkbox special-casing isn't completely ideal, but I don't
> see any way around that.
>
> - Tom
>
--
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/02537b83-c9ec-4ded-8b1f-6e03a5f0e21a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
