If the user changes a field "username" for example and then saves his changes form.has_changed() will detect correctly that the username has changed. If the user then goes back and changes the username to the old value, form.has_changed() will return True because the new input differs from the first change even though it's equal to the (true) initial value.
I also use a custom widget that displays the initial values to the user
and I don't want the intermediate changes to be displayed as initial
values in that case.
Am 16.09.2015 um 13:16 schrieb Florian Apolloner:
> What is preventing you from passing the saved changes in via initial?
>
> On Tuesday, September 15, 2015 at 10:23:02 PM UTC+2, Moritz S. wrote:
>
> Hello,
>
> currently you can add data to forms either by passing it into the
> "initial" or the "data" argument of Form. However sometimes I have the
> need to add data to a Form that isn't request.POST and doesn't come
> from
> an http request.
>
> My use case is the following:
>
> I have a form where a user can edit a model. So I pass the current
> values into "initial". Now the user can "save" his current changes
> without saving the model instance. He can come back later and see the
> changes he already made. So "initial" is still the data from the model
> but now "data" has also be filled with the cached changes.
> Only when the user clicks on "change model" the changes will
> actually be
> made to the model.
>
> The problem now is that when the user "saves" his intermediate
> changes I
> get the data from form.cleaned_data and cache it somewhere. However
> if I
> want to display the form back to the user I have to convert the data
> from the format
>
> {'field1': 'value1', 'field2': 'value2'}
>
> into something like
>
> {'form-prefix-widget-specific-field1': 'value1',
> 'form-prefix-widget-specific-field2': 'value2'}
>
> and have to actually know how the widgets get their data.
>
> I'd like to propose a new argument to "django.forms.Form" called
> "data_values".
> Its semantics will be just like data. The difference is that it will be
> a dictionary storing the data in {'field-name': 'field-value'} format
> instead of a widget specific one.
>
> I have a branch where I sketched this new functionality here:
> https://github.com/MoritzS/django/tree/forms-data-values
> <https://github.com/MoritzS/django/tree/forms-data-values>
>
> I'd like to hear your comments on this!
>
> Moritz
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/4VrIxHRu9TU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To post to this group, send email to django-developers@googlegroups.com
> <mailto:django-developers@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/0c63b29c-dacd-45af-8caf-79229528428b%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0c63b29c-dacd-45af-8caf-79229528428b%40googlegroups.com?utm_medium=email&utm_source=footer>.
> 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/55F9534C.4040700%40googlemail.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
