On Thu, Jul 3, 2014 at 7:02 AM, Tim Graham <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. 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.
