Multiple emails form field
Field which accepts list of e-mail addresses separated by any character, except those which valid e-mail address can contain.
- multiple
- form
- field
- list
Snippet List
AntiSpamForm
A general AntiSpamForm using some tricks to prevent spam based on current [django.contrib.comments.forms](http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/forms.py). It uses a timestamp, a security hash and a honeypot field. See [AntiSpamModelForm](http://www.djangosnippets.org/snippets/1856/) too.
- forms
- spam
- form
- antispam
Form and FormSet that are defined dynamically with request-data
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.
- form
- request
- formset
AntiSpamModelForm
A general AntiSpamModelForm using some tricks to prevent spam based on current [django.contrib.comments.forms](http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/forms.py). It uses a timestamp, a security hash and a honeypot field. See [AntiSpamForm](http://www.djangosnippets.org/snippets/1925/) too.
- forms
- spam
- form
- antispam
FormWizard inside view with proper context handling and site templating support, without having to use urls.py
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages) I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order. This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
- requestcontext
- views
- context
- form
- urls.py
- wizard
- formwizard
- views.py
PartialRequiredMultiValueField
Allows the whole widget to be required but still have optional fields in it. For instance we have a NameField, which takes a firstname and lastname and optionally a middlename. With this we can just have 1 widget.
- form
- multivaluefield
Remove named field from fieldsets
This snipped removes a specific fields from the fieldsets. This is very useful to leave a field 'out' in the admin, likewise: def get_fieldsets(self, request, obj=None): fieldsets = super(BlaModelAdmin, self).get_fieldsets(request, obj) if not request.user.has_perm('change_blah'): remove_from_fieldsets(fieldsets, ('blah',))
- admin
- fieldset
- form
- field
- fieldsets
UserProfileForm
We often need to use a Profile form and we want to be able to modify the first_name, last_name and sometimes the email address. Here is how I do it. In this case I want to check the email so I did a specific form for it. But it is quite easy to add it.
- user
- profile
- form
Limit the output of a field
This is a really simple snippet , but is not documented well ... Whit this , you can limit the output of one field in 25 characters before you test that is equal or over 30 characters! Note that the snippet cut the text and add three points at the end (...) Enjoy!
- form
- field
- output
- limit
Stacked/Grouped Forms 2 - easy rendering forms
This snippet was inspired by [1783](http://www.djangosnippets.org/snippets/1783/). It allows simply create groups of fields for template rendering.
- template
- fields
- forms
- templates
- fieldset
- form
- object
- field
- fieldsets
- groups
- stacked
- descriptor
A Lazy ChoiceField implementation
Sometimes it is useful to have a ChoiceField which calculates its choices at runtime, when a new instance of a form containing it, is generated. And this is what `LazyChoiceField` does. The `choices` argument must be an *iterable* as for `ChoiceField`. **Usage example** from django import forms DynamicApplicationList = [] class MyForm(forms.Form): dynamic_choice = LazyChoiceField(choices = DynamicApplicationList) `DynamicApplicationList` can now be updated dynamically.
- fields
- choice
- forms
- form
- field
Custom CheckboxSelectMultiple
A simple widget to custom the CheckboxSelectMultiple widget.
- checkboxselectmultiple
- form
- widget
ContentType Form
When working with the ContentType model there are generally two issues. 1. Models are listed in the table but not imported. 2. Unicode only returns model not application so being able to select a a app/model is sometimes difficult when to applications have a model with the same name. This snippet gets a listing of imported models and creates a drop down for selection. I also included a function that uses the returned from to get and save the correct ContentType within the primary model.
- form
- contenttype
TemplateForm
This a mixin that can be used to render forms from predefined templates instead of using .as_table / .as_p / .as_ul
- template
- form
Arbitrary length formset
A formset class where you can add forms as you discover the need within your code. There is also the ability to add ManagmentForm fields. If you ever found yourself in a situation where 1) you have repeated forms that need to be displayed in different locations, or 2) if you find the application logic works better if you add forms as you discover you need them, this code will help you out. Below is pseudo code based on a real implementation I used. Each form had a save button and the SELECTED_PAYMENT field was set through JavaScript. It is very difficult to use JavaScript with repeated forms, without using a formset. from myProject.myApp import myFormsUtils from myProject.myApp.forms import PaymentForm SELECTED_PAYMENT = 'SELECTED_PAYMENT' # extra_fields format: {Field name: (Field type, Initial value)} l_extra_fields = {SELECTED_PAYMENT: (forms.IntegerField, -1)} PaymentFormSetType = myFormsUtils.formset_factory(PaymentForm, extra=0, extra_fields=l_extra_fields) if request.method == 'POST': paymentFormSet = PaymentFormSetType(data=request.POST) if paymentFormSet.is_valid(): li_curFormIdx = pagaFormSet.management_form.cleaned_data[SELECTED_PAYMENT] paymntForm = paymentFormSet.forms[li_curFormIdx] ... do stuff ... # To generate the formset paymentFormSet = PagamentoFormSetType() # You can re-add a form retrieved (as in the one above) l_form = paymentFormSet.add_form(paymntForm) # Or use the add function just like creating a new form l_form = paymentFormSet.add_form(personID=argPersonID, propID=argPropID, year=argYr, amt=lc_Amt) I then stored the `l_form` variables above directly into a unique Context structure and displayed them each individually in my template. Of course this also meant that I also had to output the `paymentFormSet.management_form` explicitly within my template. EDIT 09-11-2009: Modified the initial_form_count() method to properly handle initial form values in conjunction with dynamically added forms.
- form
- formset
- factory
- arbitrary-length
99 snippets posted so far.