I wanted to mark rows with an erroneous input with 'class="error"' and move the errorlist below the input tag so I wrote a NormalRowFormatter which behaves like a format string by overwriting \_\_mod\_\_.
Examples:
class MyForm(PrettyBaseForm, forms.Form):
# add your fields here
SomethingForm = form_for_model(Something, form=PrettyBaseForm)
When adding fields in the __init__ of a newform, and you don't want the fields to be added *after* the class-attribute fields, this is a possibility... This is a bad example as the email_from could just as well have been defined as a class variable!
**Now redundant any anything >0.96**, as `form_for_*` methods now have a `fields` attribute
`formfield_callback`s are a bit difficult to use, here's a helper method to create a callback function to use with the `form_for_instance` and `form_for_model` methods.
Example usage:
person_callback = new_callback(exclude=['password', 'can_add_staff', 'is_staff'])
def form_for_person(person):
return form_for_instance(person, formfield_callback=person_callback)
The newforms package allows you to simply add new field types to your forms.
This snippet shows the addition of a new type of field, to make sure the user enters sensible currency values (either with no decimal, or two-decimal places), and a custom widget to make sure that the value is displayed correctly when the user sees the form.
The CurrencyInput widget simply tries to display the current value in floating point 2-decimal places format (and gives up if it can't). The CurrencyField makes sure that the input value matches a regular expression, and when it is asked to clean the value it converts it to a float.
The regex here limits the amount to 99,999.99 or less. This is within the bounds of accuracy of python's float value. If you want to use truly huge values for the amount, then you'll face problems with the floating point not being able to represent the values you enter, and so the conversion to floating point in the field will fail. In this case it would be better to use python longs, and used a fixed point interpretation.
This code generates a CSV file for a model. The URL is http://example.com/spreadsheets/app_label/model_name/ (replace spreadsheets for admin, from the URL for the model's admin page.)
I'm finding this much more efficient (from a coding perspective) than using the `render_to_response` shortcut.
It looks complex, but it's simple to use: just look at the example in the docstring.
Call this script `renderer.py` and chuck it in your project root.
How to proceed to add a custom validator to a newforms field : you just need to create a new class derivated from forms.YourField with a custom clean method. Do not forget the line super(UserField, self).clean(value) ; in our case, it verifies the field attributes : min_length, max_length or required.
More explications (in French) : [des validateurs personnalisés pour Django](http://www.aozeo.com/blog/67-django-newforms-validateurs-personnalises)
You can download these files from [here](http://huangyilib.googlecode.com/svn/trunk/mashi_django)
Django template, mako, genshi, they are the best three templates in python, aren't they?
How to use these files ?
[Using Mako in Django](http://fuzzythinker.blogspot.com/2007/04/using-mako-in-django.html)
-- by John Leung
A page we used on Curse to stop users who are new, who are using old browsers (ones who usually have extreme issues with CSS handling) and recommend they update.
Can easily be modified to suit your needs.
The loremipsum tag generates random content for use in mockups. It takes this content from Cicero's De finibus bonorum et malorum. By default you get a random number of paragraphs up to 6, but you can affect this behaviour by passing in parameters for quantity and units. Units can be "paragraphs" or "words"; the default is paragraphs. Quantity dictates the number of units returned.
If your django.conf.settings.TEMPLATE_DEBUG is True, then no output is returned, so you should be OK in the event you leave the tag in a production template.
Syntax:
{% loremipsum %}
{% loremipsum quantity="3" units="paragraphs" %}
By leaving the behaviour as random, you can see how your layout handles varying amounts of content. Handy, especially for multi-column pages. [Here's a stoopid site](http://lakes.knoxzilla.com/) where I'm playing with random text, pictures, business listings, etc.
I do plan to add a "corpus" parameter to allow you to put your own corpus between lorumipsum and endloremipsum tags and a template parameter to specify the corpus should come from a template, but this has suited me well thus far.
In my sphinx documentation I really wanted a nice clean list of the fields on my Django models. The most obvious way of doing this is to add ":param blah:" tags to the docstring, but this takes a long time to implement and violates DRY principles when you already have lots of nice help text in the model definition. Another way is to use "#:" comments on attributes, but this approach suffers from the same issues as the previous method with the additional problem of Sphinx crapping out on file and custom fields.
So anyway, this is my solution. It uses the Sphinx docstring processing callback to intercept any objects that inherit from django.models.Model and creates a nice param list of all the fields on that model. Param descriptions come from the field's help text or verbose name if no help text is defined.
To use this, just add it to the end of your source/conf.py, filling out the project path as appropriate. You may be able to skip the Django environment setup lines if you're adding this to a Sphinx doc that already has Django models set up.
You're looking at the most-bookmarked snippets on the site; if you'd like to help useful snippets show up here, sign up for an account and you'll get your own bookmarks list.