This is a function to take a Q object and construct a function which returns a boolean. This lets you use the exact same filter syntax that Django's managers use and apply it inside list comprehensions, or to non-persistent objects, or to objects of different types with the same attribute names.
Daniel Roseman's snippet, updated will all fixes mentioned in the comments of the first version + some other things to make it work under Django 1.4.
South, and dumpdata are working.
There's an ugly int(....) at the validate function in order to cast each value as an integer before comparing it to default choices : I needed this, but if you're storing strings values, just remove the int(......) wrapper.
-------------------------------------
Orginal readme
Usually you want to store multiple choices as a manytomany link to another table. Sometimes however it is useful to store them in the model itself. This field implements a model field and an accompanying formfield to store multiple choices as a comma-separated list of values, using the normal CHOICES attribute.
You'll need to set maxlength long enough to cope with the maximum number of choices, plus a comma for each.
The normal get_FOO_display() method returns a comma-delimited string of the expanded values of the selected choices.
The formfield takes an optional max_choices parameter to validate a maximum number of choices.
This math captcha field and widget was inspired by Justin Quick's django-math-captcha, but I wanted to make it into one form field and not have anything in settings.py. I removed the division and modulo operators to avoid people having to input fractions, and just randomly select the operator.
It leverages Django's built-in MultiValueField to set up the hidden hashed answer to compare the user's input to instead of rendering strings for the fields like django-math-captcha does.
Unit tests soon to follow, but this is used in production at: http://btaylorweb.com/. Enjoy!
When you want to save integers to the db, you usually have the choice between 16-, 32- and 64-bit Integers (also 8- and 24-bit for MySQL). If that doesn't fit your needs and you want to use your db-memory more efficient, this field might be handy to you.
Imagine you have 3 numbers, but need only 10 bit to encode each (i.e. from 0 to 1000). Instead of creating 3 smallint-fields (48 bit), you can create one 'ByteSplitterField' which implements 3 'subfields' and automatically encodes them inside a 32 bit integer. You don't have to take care how each 10-bit chunk is encoded into the 32-bit integer, it's all handled by the field (see also field's description).
Additionally, the Field offers opportunity to use decimal_places for each of your subfields. These are 'binary decimal places', meaning the integer-content is automatically divided by 2, 4, 8, etc. when you fetch the value from the field.
You can also specify how values are rounded ('round' parameter) and what happens when you try to save a value out of range ('overflow' parameter)
Not implemented (maybe in the future if I should need it sometime):
* signed values. All values are positive right now!
* real (10-based) decimal places (actually you could probably directly use DecimalFields here)
* further space optimization, i.e. saving into CharField that's length can be chosen byte-wise
Needed a function to check if any field in an instance has changed. If so update a datetime field to now to keep track of changes. This function is an override of the save function in the model.
These decorators can be used to make some model/form fields readonly.
**Sample usage:**
# Use this decorator on form with readonly fields.`
@modelform_with_readonly_fields`
class FooAdminForm(forms.ModelForm):`
...
# This decorator shoud be used to protect selected fields `
# from modification after initial save.`
@has_readonly_fields`
class Foo(models.Model):`
read_only_fields = ('name', )`
...
**Result** will be the same as shown in this post: [Readonly field](http://stackoverflow.com/questions/324477/in-a-django-form-how-to-make-a-field-readonly-or-disabled-so-that-it-cannot-be/1424453#1424453) and
[Readonly model field](http://www.djangozen.com/blog/read-only-fields-in-models)
PushPinImageField is a Django form field that is a sub-class of an ImageField. The field accepts an image to upload and based on certain settings, notably the size of the resulting image, the sizes and colors of 3 different borders, as well as the color of the push pin, a re-sized image is created with a colorized push pin in the top-center.
A live demo of the field as well as more detailed usage instructions are available as a [blog entry](http://www.robmisio.com/blog/2/).
Tag for iterating through the fields of an object from a template.
The tag is passed two string arguments, the name of the model to use (which is then looked up in the context dictionary), and the format string. The format string should include two string place holders.
The tag will output each field name and value according to the format string supplied.
This is a very flexible and concise way to [Handle choices the right way](http://www.b-list.org/weblog/2007/nov/02/handle-choices-right-way/) in model fields.
* Preserves order.
* Allows both a human-readable value for display in form `<select>`s as well as a code-friendly short name.
* Mimic's Django's canonical [choices format](http://docs.djangoproject.com/en/1.3/ref/models/fields/#choices).
* Doesn't restrict the value type.
* Memory efficient.
Inspired by [snippet 2373](http://djangosnippets.org/snippets/2373/) to use namedtuples as model field choices.
Nice to name your constant multiple choice fields in models, this is one way of doing that. Sorry I haven't looked into existing alternatives. But this approach worked for me.
**Purpose**
We often need to store x,y, width and height for a model, we can store all these values in same field by having custom field.
**How to Use**
Save this code in *customfields.py* and in your model
>*from customfields import FrameField*
>*class MyModel(models,Model)*
>* frame = FrameField()*
And in your in views, you can use as follows
>*model = MyModel.objects.get(1)*
>*print model.frame.x, model.frame.y, model.frame.width, model.frame.height*
Small changes to [Snippet 1694](http://djangosnippets.org/snippets/1694/) to that QueryAPI works for django 1.2 and higher.
Changes:
* Replaced `get_db_prep_value` with `get_prep_value`.
* Replaced `get_db_prep_lookup` with modified `get_prep_lookup`.
Unlimited-length character fields in Postgres perform the same as limited-length fields, and the Postgres manual suggests not arbitrarily limiting these fields. Unfortunately, Django does not provide a way to access unlimited-length character fields except using TextField, which is rendered differently in forms and in the admin, and has different connotations.
LongCharField is a way to avoid putting arbitrary max_length values where they aren't required. It will only work with databases that allow VARCHAR with no numeric parameters, such as Postgres. MySQL won't work.