Skip to content

Commit

Permalink
Fixed #1049 -- Documented the need to implement flatten_data() in som…
Browse files Browse the repository at this point in the history
…e cases for custom

ChangeManipulator replacements. Thanks, Michael Radziej.


git-svn-id: http://code.djangoproject.com/svn/django/trunk@4711 bcc190cf-cafb-0310-a4f2-bffc1f526a37
  • Loading branch information
malcolmt committed Mar 12, 2007
1 parent db03c7f commit 5295f54
Showing 1 changed file with 21 additions and 0 deletions.
21 changes: 21 additions & 0 deletions docs/forms.txt
Expand Up @@ -417,6 +417,27 @@ Here's a simple function that might drive the above form::
form = forms.FormWrapper(manipulator, new_data, errors) form = forms.FormWrapper(manipulator, new_data, errors)
return render_to_response('contact_form.html', {'form': form}) return render_to_response('contact_form.html', {'form': form})


Implementing ``flatten_data`` for custom manipulators
------------------------------------------------------

It is possible (although rarely needed) to replace the default automatically
created manipulators on a model with your own custom manipulators. If you do
this and you are intending to use those models in generic views, you should
also define a ``flatten_data`` method in any ``ChangeManipulator`` replacement.
This should act like the default ``flatten_data`` and return a dictionary
mapping field names to their values, like so::

def flatten_data(self):
obj = self.original_object
return dict(
from = obj.from,
subject = obj.subject,
...
)

In this way, your new change manipulator will act exactly like the default
version.

``FileField`` and ``ImageField`` special cases ``FileField`` and ``ImageField`` special cases
============================================== ==============================================


Expand Down

0 comments on commit 5295f54

Please sign in to comment.