Hi, I'm the author of Ticket #25227 Add utility method
`get_updated_model()` to `ModelForm` and its accompanying patch.
Ticket: https://code.djangoproject.com/ticket/25227
Patch: https://github.com/django/django/pull/5105
Here's the writeup to save everyone a click:
Add util
Hi, I'm the author of Ticket #25227 Add utility method
> `get_updated_model()` to `ModelForm` and its accompanying patch.
>
> Ticket: https://code.djangoproject.com/ticket/25227
>
> Patch: https://github.com/django/django/pull/5105
>
> Here's the writ
actor also enhances the
readability of the code to a prospective Django contributor diving into the
source code for the first time.
Thanks,
Javier
> On Thursday, August 6, 2015 at 7:34:54 AM UTC-4, Javier Candeira wrote:
>>
>> Hi, I'm the author of Ticket #25227 Add
let me also point this out: in separating the commit=False and
> commit=True paths of ModelForm.save() into the two functions
> get_updated_instance() and save_instance(), this refactor also enhances the
> readability of the code to a prospective Django contributor diving into the
> sou
for decades when I learnt Django. Many people following the
>> tutorials haven't. In some cases, they haven't even been alive for one
>> decade.
>>
>> I'd like to hear the opinion of people who teach newcomers to
>> programming, but let me also po
/docs.djangoproject.com/en/1.8/topics/forms/modelforms/#the-save-method>
>>>
>>> Django documentation is stellar. This means that the "save(save=False)"
>>> API antipattern is very well documented indeed. This doesn't make it less
>>> of an antipa
oesn't seem worth it to me.
>>>>
>>>> >
>>>> https://docs.djangoproject.com/en/1.8/topics/forms/modelforms/#the-save-method
>>>>
>>>> <https://docs.djangoproject.com/en/1.8/topics/forms/modelforms/#the-save-method>
>>>
>>>> recall
>>>> having trouble understanding how this worked when I learned Django and
>>>> introducing a new way to duplicate functionality of a 10 year old pattern
>>>> doesn't seem worth it to me.
>>>>
>>>> >
dated_model()
>>>>> # do stuff to model
>>>>> if commit:
>>>>> model.save()
>>>>> form.save_m2m()
>>>>>
>>>>> > I think Django's documentation describes the behavio
ason for rejecting my patch, "discouraging use of
>>>>>> super()" should hardly be it.
>>>>>>
>>>>>> I could also include a documentation patch recommending the use of
>>>>>> super() for the commit=True path of save(), but I thi
>> model = super(MyForm, self).save(commit=False)
>>>>>>> # do stuff to model
>>>>>>> if commit:
>>>>>>> super(MyForm, self).save()
>>>>>>>
>>>>>>> These two are equivalen
;
>>>>>>>> class MyForm(ModelForm):
>>>>>>>> def save(commit=True):
>>>>>>>> model = super(MyForm, self).save(commit=False)
>>>>>>>> # do stuff to model
>>>>>>>
> Add utility method get_updated_model() to ModelForm
>
>
I think the problem I have with the name here is that I often think of the
Model as the class definition and not the instance object that the model
makes. When I got passing around model classes like a mad django diva, I
might get confu
2015-08-07 16:51 GMT+02:00 Martin Owens :
> Could we use something simple like 'update()' and 'commit()' to which save
> would call both?
Or `.apply()` and `.commit()` not to suggest that the form gets
updated in any way.
--
Patryk Zawadzki
I solve problems.
--
You received this message becaus
On Saturday, 8 August 2015 02:38:09 UTC+10, Patryk Zawadzki wrote:
>
> 2015-08-07 16:51 GMT+02:00 Martin Owens >:
>
> > Could we use something simple like 'update()' and 'commit()' to which
> save
> > would call both?
>
> Or `.apply()` and `.commit()` not to suggest that the form gets
> update
Ok, so I rebased on Tim Graham's refactor and bugfix of ModelForm, and now
the API is as follows:
`.save()` commits to the database. In `ModelForm`, it returns the
associated instance, and in `FormSet`, the list of associated instances. It
runs `.apply()` first.
`.apply()` just returns the ins
"I like `.apply()`, since it can either suggest that it's applying the
form's data to the instance, or applies the validation rules to the form
data."
I don't think it does either of those things though? I don't find the name
intuitive for what it does. I think the purpose of "save(commit=Fals
On Monday, 10 August 2015 21:36:27 UTC+10, Tim Graham wrote:
>
> "I like `.apply()`, since it can either suggest that it's applying the
> form's data to the instance, or applies the validation rules to the form
> data."
>
> I don't think it does either of those things though? I don't find the nam
On Monday, 10 August 2015 22:30:51 UTC+10, Javier Candeira wrote:
>
> Also, is there anywhere I have missed in the documentation that explains
> how deprecation works in the project? If we go for such a break with the
> existing API, my patch would need to keep the current API working for a
> w
Yes, the idea is that ModelForm.save() method could become (after
deprecation finishes):
def save(self):
"""
Save this form's self.instance object and M2M data. Return the model
instance.
"""
if self.errors:
raise ValueError(
"The %s could not be %s because
Hi Tim,
On 08/10/2015 11:07 AM, Tim Graham wrote:
> Yes, the idea is that ModelForm.save() method could become (after
> deprecation finishes):
>
> def save(self):
> """
> Save this form's self.instance object and M2M data. Return the model
> instance.
> """
> if self.errors:
>
Yes, I agree that a documentation change should be sufficient (although I
still didn't look at the formsets situation).
On Monday, August 10, 2015 at 11:57:19 AM UTC-4, Carl Meyer wrote:
>
> Hi Tim,
>
> On 08/10/2015 11:07 AM, Tim Graham wrote:
> > Yes, the idea is that ModelForm.save() method
Ok, I'm heading for work now, will give it a spin this evening.
Thanks everyone for your comments!
J
On Tuesday, 11 August 2015 02:07:07 UTC+10, Tim Graham wrote:
>
> Yes, I agree that a documentation change should be sufficient (although I
> still didn't look at the formsets situation).
>
> On
I'm not super convinced that form.instance is widely better than
form.save(commit=False).
That's even more true if we're not sufficiently convinced by it that we'd
be deprecating the existing style.
It would:
* Promote making views making in-place changes on the instance -> doesn't
tend to be
Unless I missed something here, I am strongly -1 on this PR:
1) Form.save(commit=False) is obvious: don't propagate to the database,
stop at the object level (I'll manage that later, I don't want to hit the
database 2 times, there are some dependencies I need to manage etc).
When I read that lin
25 matches
Mail list logo
