Here's a "book" analogy to what I am doing. I am sending out a bunch
of forms to the user. Each form contains the title of a book (my
"tile") and an input field where the user is being asked to input the
author of the book. When the view.py code receives the post data, for
each form where the user has input the author, the view.py code will
create a book object with the title from the form and the author that
the user input.
So when I get an author, I need to identify which title it goes with.
When I was writing the code I felt uncertain about identifying which
title the form was for based on index. I thought that would work, but
it seemed somehow safer to simply have it encoded in the same form.
That way I don't have to match up indexes - instead I just ask the
form what the title is. So that's why I sent the title as a hidden
input.
The reason that has_changed() was false was simply that in my
debugging, on the client side I was not filling out the form. I was
just leaving it blank. Then in view.py I was looking at the form to
verify that I could get back the book title, and that's when I
encountered the fact that cleaned_data was empty.
What can I say ... I've been trying a lot of different things to
really get a handle on this and it's taken me down a lot of strange
paths.
I'm sure that you are right that I can identify the "book" based on
its index in the formset.
Once again, thanks for your insights.
Margie
On Mar 4, 8:42 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Wed, 2009-03-04 at 00:28 -0800,Margiewrote:
>
> [...]
>
> > After debugging into the source some more, I'm finding that my the
> > problem is related to the fact that empty_permitted is getting set to
> > True when all of my forms are considered "extra.
>
> Which is reasonable. "Extra" here means "optional".
>
> > Specifically, in site-
> > packages/django/forms/forms.py, in the full_clean() function, I find
> > that when empty_permitted is set to True, this code executes, which
> > drops me out of the code without setting cleaned_data at all:
>
> > # If the form is permitted to be empty, and none of the form
> > data has
> > # changed from the initial data, short circuit any validation.
> > if self.empty_permitted and not self.has_changed():
> > return
>
> This will only happen if none of the data has changed. That's the point
> of the call to has_changed().
>
>
>
> > It seems to me that if I pass in initial when I create the
> > TaskTileDetailFormSet, ie, like this:
>
> > initial = []
> > for tile in tileList:
> > initial.append({'tile': tile.id})
>
> > taskTileDetailFormSet = TaskTileDetailFormSet(data,
> > tiles=tileList, initial=initial)
>
> > then empty_permitted gets set to False ibecause my initial_form_count
> > is non-zero. IE, in site-packages/django/forms/formsets.py, in
> > _construct_form(), in thh code that looks like this:
>
> > # Allow extra forms to be empty.
> > if i >= self._initial_form_count:
> > defaults['empty_permitted'] = True
>
> > But if I pass initial in via my own _construct_form() function as you
> > suggested, then I have no initial data, so all of my forms are
> > "extra". IN this case self._initial_form_count is 0, and it seems
> > that the result is that cleaned_data doesn't get set correctly.
>
> That would only be the case if none of the data for the form has
> changed. If you've changed something on the form (from the initial
> data's perspective), has_changed() should be returning True.
>
>
>
> > I am probably far from undrestanding this, but if what I said is
> > atually true, it seems like this is actually a bug? The bug being
> > that cleaned_data is not getting set correctly when the forms are
> > created as "extra" forms. Perhaps cleaned_data is not supposed to get
> > set in this case?
>
> Formsets are not entirely broken. Let's not think of zebras in
> preference to horses when we hear the hoof-beats. If formsets and empty
> forms didn't work, the entire admin application would be broken in
> interesting ways, for example.
>
> You've found the right pieces of code, but you aren't examining why they
> are falling through to skipping validation. The conditional test is
> important. Why isn't has_changed() returning True for your particular
> setup? Do you have to also subclass that based on the data changes
> you're making, perhaps?
>
> > The whole reason that I happened upon this is
> > beacuse I am trying to identify which form is which, so I was looking
> > at cleaned_data['tile']. I set that myself anyway, so I can just look
> > at data['tile'].
>
> This is something I don't understand. If you are setting up the "tile"
> each time in your view, why is it having to be sent to the form? Either
> it's data you take from the form, or it's data you can always supply in
> the view. I've decided I don't understand the problem you're trying to
> solve here, so can you please (re-)explain that? I've gone back over the
> thread and I can't see a clear statement of the need for all this
> customisation, so thinking of alternative approaches is hard.
>
> Once you have somehow identified the formset, identifying each form
> inside it doesn't seem to be necessary, particularly if they're all new
> objects (after all, each form in the formset is numbered, so unique
> identifier + offset in formset is a unique way of identifying each
> component form). Why not just have a single identifier for the entire
> formset?
>
> If you can do that, then the problem falls out easily: the identifier
> doesn't go in the formset at all. It goes into a separate form class
> that only contains this hidden field. Remember that Django form classes
> correspond to a fragment of an HTML form, so you can pass multiple form
> instance (or a form instance plus a formset instance) to the template.
>
> Alternatively, you could override Formset.__init__ and put the
> identifier into the ManagementForm instance. That doesn't feel quite as
> nice to me, since it's kind of relying on a bunch of implementation
> details (I'd almost like ManagementForm to be overridable, probably as a
> class attribute).
>
> Regards,
> Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
