On Thu, Jul 3, 2014 at 7:02 AM, Tim Graham <timogra...@gmail.com> wrote: > Another suggestion: could you include the field on the form but use a > HiddenInput widget?
I could, but originally I wanted to avoid this. The container_id should not be editable by the user. Including this in the form seems to make a statement against this. I could experiment making this readonly so the form validates that the value is unchanged. But in the end, this seems to be a workaround to implement my original suggestion. That is, when instantiating the formset, pass a dictionary of "static" fields and their data, that are not rendered as part of the form HTML, but could be used in: * Default queryset (could always be overridden) * Creating new instances * Validating form data I suppose readonly hidden inputs would achieve the same effect, but it seems there is no need for the data to be a part of the rendered HTML form. I'll play around with this, thanks for the suggestion. > I think in your case you > should call model.full_clean() after form validation and handle any unique > errors there… I experimented with this, but this will not work. The method model.full_clean() validates against the database. But the form needs to validate against unsaved data. I imagine this is why BaseModelFormSet.validate_unique() was written in the first place. -- You received this message because you are subscribed to the Google Groups "Django developers" 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/CADhq2b5f_oN%3D2-V-WDqv3omPyu2zpKddXTiDNXhWQNd3-u%3DU-Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
