clean validation for dynamic form fields
I needed a way to validate non-required, dynamically generated form fields, and clean provided the best solution for this problem.
- forms
- validation
- dynamic-forms
I needed a way to validate non-required, dynamically generated form fields, and clean provided the best solution for this problem.
Sometimes we need to build a ChoiceField from data in a Model or more than just one model via fk's but the ModelChoiceField is not *that* flexible. So, in order to obtain a list of tuples with pk and a descriptive text for the choices parameter of the ChoiceField use this little function.
This FloatField replacement allows users to enter math expressions, such as: 4/5 + sqrt(32) And will evaluate them safely when the field's clean() function is called. In the example above, it will evaluate to a float value of about 6.457. Reference: [http://lybniz2.sourceforge.net/safeeval.html](http://lybniz2.sourceforge.net/safeeval.html) The available functions are listed herein. Note that the from __future__ import division causes integer division expressions to be evaluated as floats. For example "1/2" evaluates as 0.5 when it would otherwise have evaluated to 0 (assuming Python 2.X).
I was looking for a way to save screen real estate, by using icons instead of labels for my list of choices, which in addition should be displayed as horizontal radio buttons. For example, I wanted to use thumbs_up.gif instead of "approve". I found a HorizontalRadioRenderer here: [https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons](https://wikis.utexas.edu/display/~bm6432/Django-Modifying+RadioSelect+Widget+to+have+horizontal+buttons) Thanks to Barry McClendon for this snippet! At first, I tried to achieve display of icons instead of labels by modifying the render method, but after a while I gave up on that and decided to just use the choices tuple. This doesn't work too well with a select box (no icons, no text), but in combination with a radio widget it looks quite nice. If you mark the strings for translation, you can also easily change icons, alt and title for each language.
Template designers often require access to individual form fields or sets of form fields to control complex form layouts. While this is possible via looping through form fields in the template it can lead to ugly logic inside templates as well as losing the ability to use the as_* form rendering methods. This class when mixed into a form class provides hooks for template designers to access individual fields or sets of fields based on various criteria such as field name prefix or fields appearing before or after certain fields in the form, while still being able to use the as_* form rendering methods against these fields.
Suitable for use with DecimalField. Handy for accurate timing input (think sports, racing etc.).
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.
Useful in sumbiting data . Remember to use form.save_m2m() :)
Create form atribute(s) for grouping (bound) fields.
A Django Form for creating a browser-based upload form that pushes files to Amazon S3. See http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1434
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.
Sometimes, we need to pass hidden fields with an initial value in forms but cannot trust the returned values because it could have been tampered. So here is a form that adds an additional 'hidden' field (called 'form_hash') that hashes all the initial value of hidden fields and checks for tampering. Pretty straightforward to use.
this solves a common problem where you want to specify html tag attributes for form fields in the template itself and not have to do it by writing a custom form class. eg. the size of the field, css classes, tabindex etc. usage: {% render_field form.comments "cols=40,rows=5,class=text,tabindex=2" %} where form.comments is a form field with a text area widget it will show data (if the form is bound or if there is initial data) and will display errors if the field has errors
It is often convenient to be able to specify form field defaults via GET parameters, such as /contact-us/?reason=Sales (where "reason" is the name of a form field for which we want a default value of "Sales"). This snippet shows how to set a form's initial field values from matching GET parameters while safely ignoring unexpected parameters.
This snippet was inspired by [1783](http://www.djangosnippets.org/snippets/1783/). It allows simply create groups of fields for template rendering.
141 snippets posted so far.