This method will return an inline formset class that validates values across the given field are unique among all forms. For instance: ApprovedUserFormSet = inlineformset_factory(Request, ApprovedUser, formset=unique_field_formset('email'), form=ApprovedUserForm) Will make sure all ApprovedUser objects created for the Request have unique "email" fields.
**What It Is** This is a JavaScript-based solution to dynamically add and remove forms in formsets and inlineformsets. It requires jQuery. Originally based on this Snippet: https://djangosnippets.org/snippets/1389/ I have done a lot of work to make it OO, and am using it in production on pages with multiple inlineformsets, and even nested inlineformsets (I call it, "Inlineformset Inception"). My hope is that the code and example are enough to show how it works. **Usage Details** In the example usage, I am using a CSS class, 'light', to make every other form have a light background color. My form placeholder is an element with an ID of 'formset-placeholder' (the default). And the form selector is a class name of 'dynamic-form' (the default). When I have time, I will create a GitHub repository with the code and completed examples.
If using javascript is not an option, you can use something like this code to have a variable number of subforms. This code uses crispy-forms, but it is totally dispensable.
example formset views for multiple image upload hope its useful ...
Sometimes we need divide forms in fieldsets, but this make us declare all fields in HTML template manually. This class is to help you to do this by a easy way. **How to use** First, download this file as name "sectioned_form.py" Later, turn your form inherited from the class **SectionedForm**, override method "_html_output" and declare fieldsets and fieldset_template attribute, like below: from sectioned_form import SectionedForm class MyForm(forms.ModelForm, SectionedForm): fieldsets = ( (None, ('name','age','date')), (_('Documents'), ('number','doc_id')), ) fieldset_template = "<h2>%s</h2>" def _html_output(self, *args, **kwargs): return SectionedForm._html_output(self, *args, **kwargs)
As there is no straight way to re-produce the real tabular inline formsets you get in django-admin, here is how this template has to look like if you do it form your own formsets generated from formset factories.
Background ========== Two years ago, Malcolm Tredinnick put up an excellent post about doing dynamic Django forms. There have been several excellent write-ups on it since - Google is your friend. One year ago, I attempted to make a dynamic Formset - see [this snippet](http://www.djangosnippets.org/snippets/1290/). Malcolm posted a cleaner solution two weeks later, and I liked his solution better. Some time after that happened, his site tanked. I'm re-posting my snippet using his technique, so that everyone can see how it is done. Credit to goes to Malcolm - I'm just the messenger. If his site ever comes back up , check out his complex formset post [here](http://www.pointy-stick.com/blog/2009/01/23/advanced-formset-usage-django/). I'll use Malcolm's example code, with as few changes as possible to use a formset. The models and form don't change, and the template is almost identical. I won't reproduce all of Malcolm's code - I'm just show the form setup. There are no models here - you'll have to use your imagination for Quiz, Question, and Answer models. He did some fancy validation as well - I'm not going to here. Problem ======= Build a formset based on dynamically created forms. Solution ======== The core idea in this code is found in the `_construct_form` method. Typically, this is where a formset makes new forms - it handles indexing them so that everything is nice and unique. We can take advantage of this by overriding the method and inserting a `kwarg` that will be passed on to our form class, then calling the parent `_contruct_form` method to let it finish doing everything else for us. This is what Malcolm, a core Django developer, knows about, and I, a random Django user, typically do not. Code ==== This pattern greatly simplifies building formsets dynamically, and it really only requires a few bits of knowledge. 1. If we `pop()` special arguments out of `kwargs` dictionaries, we then can pass the remaining `kwargs` along to parent methods and let them do the rest of the setup for us. See code tricks #1 and #3. 2. If we have a form and need to add dynamic fields that we didn't declare the usual way, we can just add them to the `self.fields` dictionary. See code trick #2. 3. If we need to add forms dynamically to a formset, we can use the `self.extra` variable to specify how many we want, based on the length of a custom queryset. See code trick #4. 4. If we want to pass some special arguments to a form that will be part of a formset when it is constructed, we can add them to the `kwargs` dict in `_construct_form`, taking advantage of the `index` variable to track which object from our queryset we wanted. See code trick #5.
Generate the form for an InlineModelAdmin. Usefull for ajaxing in a change in the Inline
If you read the docstring and the example you should get a clue what this Code does. I didn't want a big function everytime that handles every specific form, formset combinations so this how i can add/edit Models with specific Forms given to the magic_handle_inlineformsets function. It also works for Forms without innline_formsets.
Problem ======= The FormPreview class provided by contrib.formtools helps automate a common workflow. You display a form, then force a preview, then finally allow a submit. If the form gets tampered with, the original form gets redisplayed. Unfortunately, this class can only be used when you have an html form that is backed by exactly one Django form. No formsets, no html forms backed by more than one Django form. Solution ======== I was asked to create exactly this sort of workflow for a highly complex form + formset. The ComplexFormPreview class provides a base class to help with this problem. As with FormPreview, you must override a few functions. Code ==== The abstract ComplexFormPreview class can live anywhere on your python path. Import it and subclass is exactly like you would contrib.formtools FormPreview. The self.state dictionary is passed to all response calls as the context for your templates. Add any objects you need in your template to this dictionary. This includes all forms, formsets, and any additional variables you want in your template context. Override the parse_params if you need to get any args/kwargs from your url. Save these values in self.state if you want them in your template context. Override the init_forms method to do setup for all of your forms and formsets. Save all your forms in self.state. You should provide a unique prefix for all forms and formsets on the page to avoid id collisions in html. *VERY IMPORTANT NOTE*: init_forms is called with a kwargs dictionary. You need to pass **kwargs to all of your form definations in init_forms. This is how the POST data is going to be passed to your forms and formsets. *VERY IMPORTANT NOTE No. 2*: all of the validation is handled inside the class - all forms will be found and validated, and we will only proceed when everything is found to be valid. This means that you can use the class as a view directly, or provide a thin wrapper function around it if you want. Override the done method to handle what should be done once your user has successfully previewed and submitted the form. Usually, this will involve calling one or more save() calls to your various forms and formsets. Because you now have multiple forms, the default contrib.formtools templates don't work. You must make custom templates that reference all of your various forms. The stage_field, hash_field, and hash_value fields are used exactly like the formtools examples. Follow the basic layout demonstrated in the example templates, and substitute your custom forms for the default form. Example views.py ================ The views.py demonstrated here has many hooks into my project, including using some [complex formset classes](http://www.djangosnippets.org/snippets/1290/). It won't work for you without being customized, but it will demonstrate how to override the default ComplexFormPreview.
If you need dynamical formsets you can use `{{ empty_form }}` in template and even makeup it.
Field used to cutomize inline formset
Small usability feature to show one number of additional formsets for new object & another for created.
I needed to display formset into table and I didn´t like solution I have found. So I have written this simple tag you can use it in templates like this: ` {% for row in formset|square_it:6 %} <tr> <td> </td> {% for form in row %} <td> {% for field in form %} {{ field }} {% endfor %} </td> {% endfor %} `
This is how you can access the user's request in the Form or FormSet definition, e.g. to define the choices of a ChoiceField dynamically. Either you use it for a single Form or a whole FormSet, just pass the view's request into the Form or FormSet instantiation.