the trick was:

        if form.is_valid and formset.is_valid: # All validation rules
pass
            new_idea = form.save()
            formset_models = formset.save(commit=False)
            for f in formset_models:
                f.projectidea = new_idea
                f.save()

On Dec 3, 10:57 am, andreas schmid <a.schmi...@gmail.com> wrote:
> ok ppl i need an advice about my form view:
>
>     def myform(request):
>         idea_form =  ProjectideaForm
>         activity_formset = inlineformset_factory(Projectidea, Activity,
>     extra=5)
>         if request.method == 'POST':
>             form    = idea_form(request.POST)
>             formset = activity_formset(request.POST,
>     instance=Projectidea())
>             if form.is_valid and formset.is_valid: # All validation
>     rules pass
>                 new_idea = form.save()
>                 for f in formset.forms:
>                     f.save(commit=False)
>                     f.projectidea = new_idea
>                     f.save()
>                 return HttpResponseRedirect(new_idea.get_absolute_url())
>         else:
>              # An unbound form
>             form    = idea_form()
>             formset = activity_formset()
>         return render_to_response('fslform.html', {
>             'form'   : form,                                  
>             'formset': formset,
>         })
>
> this gives me
>
> myform_activity.projectidea_id may not be NULL
>
> how can i set the foreignkey of the inline forms to the actual parent
> model?
> every activity has a foreignkey to projectidea and both should be saved
> in one hit.
>
> bnl wrote:
> > Thanks.
>
> > Before I suggest anything concrete for the docs, let's see if my
> > understanding  is now right:
>
> > The problem from my point of view was that I didn't think I had any
> > hidden fields. Hence I didn't loop over them, and didn't think of
> > them  - yes, despite the massive hint in the error message ... :-(
>
> > I think the hidden field in question was in fact the id of the
> > instance (which exists for the previously saved objects) and was zero
> > for a "blank" form in the formset ... and I think this only shows up
> > as an issue when looping over forms in a formset, because the formset
> > machinery has set up, modified, and uses this hidden field - and I
> > didn't know it was there.
>
> > (Or is it always there for anything generated by a ModelForm, and I've
> > never spotted it because I always get my id from my url?)
>
> > (Is this really an edge case? It seems like something one would want
> > to do for nearly any interesting formset ... lay it out nicely ...)
>
> > Cheers
> > Bryan
>
> > On Aug 11, 9:45 am, Malcolm Tredinnick <malc...@pointy-stick.com>
> > wrote:
>
> >> On Tue, 2009-08-11 at 01:12 -0700,bnlwrote:
>
> >> [...]
>
> >>> Apologies that I'm not asking my questions in the way you'd like,
> >>> but believe me, I am cutting it down a lot ... and I appreciate that
> >>> it's still not obvious where the errors are (I would have found
> >>> them otherwise). In this case, I had cut it down to just field, and
> >>> it
> >>> exhibited the problem ... I shouldn't have included the extra line
> >>> which was just to show why I wanted to do it ...
>
> >> Trimming a problem report to the minimum required and no further is part
> >> science and part black art, so there are going to be times when you just
> >> get unlucky. In this case, however, the problem is you aren't including
> >> details so that I or anybody else can actually reproduce the problem. So
> >> you end up in a position where you have to hope the particular error
> >> message triggers a "we've seen that before" thought in somebody's head.
>
> >> A good problem report or request for help contains enough information to
> >> repeat the problem. Which means, in this case, the form class containing
> >> the field.
>
> >>> It would seem that the advice to loop over hidden fields in the
> >>> template could be promoted to the documentation.
>
> >> Well, we already document, in the main formset documentation, including
> >> the management form if you're doing manual template layout
> >> (http://docs.djangoproject.com/en/dev/topics/forms/formsets/#using-a-f...) 
> >> and we document including hidden fields if you're doing iteration over 
> >> form fields, in the main forms documentation, 
> >> (http://docs.djangoproject.com/en/dev/topics/forms/#looping-over-hidde...) 
> >> so this isn't undocumented territory.
>
> >> However, if you feel there's a clearer way to do this without giving it
> >> undue prominence -- bearing in mind it's an edge case, so shouldn't
> >> obscure the more regular usage cases or weigh those sections down with
> >> heavy details -- then please do create a patch and attach it to a
> >> ticket. Many of our documentation improvements are generated by people
> >> trying to make something clearer.
>
> >> 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 
> > athttp://groups.google.com/group/django-users?hl=en
> > -~----------~----~----~----~------~----~------~--~---
>
>

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@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.


Reply via email to