Widget for editing CommaSeparatedIntegerField with a set of checkboxes. Each checkbox corresponds to single integer value. So, choices should be pre-defined for widget.
**Example**
Assume, we need a registration form for some event with time frame for 3 days, starting at Monday. User can select any of 3 days, so we need to show 3 checkboxes.
Here's the basic example for such form:
class EventRegistrationForm(forms.Form):
days = forms.CharField(widget=NumbersSelectionWidget(
['Mon', 'Tue', 'Wed'], range(1, 4)))
After reading this article: http://blog.roseman.org.uk/2010/06/2/class-based-views-and-thread-safety/
and checking out this snippet: http://djangosnippets.org/snippets/2046/
I realized that I was using a class based view without even thinking about the consequences... so, without having to completely re-factor my existing class based views to make them singletons, I wrote this wrapper that should allow my class based views to work as I intended, and maintain state for a single request only.
By using __new__ the result of a class instantiation is not an object but the result of a method call.
This way classes can be used for views the same way as functions.
Useful if you can make sure your files will never collide unless they share the same contents.
You point to the storage parameter when you declare an ImageField and use the hashed_path class method (seemed to make sense to bundle it with the class) to build a custom upload_to method that has to generate the path based on the file contents.
Combining both will allow you to deduplicate files uploaded repeatedly.
This function solve the issue of random.shuffle that is based only on randomized shuffling (that's not a real shuffling, because many times items returned aren't shuffled enough).
This function make a randomized shuffle and after this loops long the list resorting to avoid two items with a same value in a given attribute.
When shuffling is over and there are duplicates, they are leftover to the end (and you can remove them if you set 'remove_duplicates' to True)
Run it in a separated file to see it in action.
My first snippet ;]
It's a simple inclusion tag for filtering a list of objects by a first letter using [django-filter](http://github.com/alex/django-filter)
after having this "installed" you can use it in your template like this:
{% load my_tags %}
<div class="letter_filter">
Filter by first letter: {% letters_filter "MyNiceModel" %}
</div>
for information how to use django-filter in your view go to [docs](http://github.com/alex/django-filter/blob/master/docs/usage.txt)
you should probably cache this inclusion tag since it makes 45 queries to the db (.count() > 0)
Enjoy and improve ;]
PS. some parts of this code are in Polish
This template tag attempts to get specific GET variables from request.GET. If such variables exist, it shows them as a query string (with optional "include_ampersand" mode when it puts an "&" at the end if there is a result string, or a "?" if there's none: it is used when you need to add a new variable to the query string) or as hidden input fields ("html_form" mode).
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.
The popular [django-tagging](http://code.google.com/p/django-tagging/) app has, in its implementation and semantics, a highly usable and transparent elegance -- but then you have to call methods on a Tag instances' items collection. These classes let you inline the tag name in the chain of queryset filter methods instead.
TO USE:
### models.py
...
from tagging.fields import TagField
from tagging.models import Tag as Tag
class YourModel(models.Model):
...
yourtags = TagField()
objects = TaggedManager()
...
### and then elsewhere, something like--
...
ym = YourModel.objects.order_by("-modifydate")[0]
anotherym = YourModel.objects.get(id=7) ## distinct from ym
ym.yourtags = "tag1 tag2"
anotherym.yourtags = "tag1 othertag"
ym.save()
anotherym.save()
with_tag1 = YourModel.objects.tagged('tag1')
with_tag2 = YourModel.objects.tagged('tag2').order_by('-modifydate')
print ym in with_tag1 ## True
print anotherym in with_tag1 ## True
print ym in with_tag2 ## False
... since these are QuerySets, you can easily create unions (e.g. `with_tag1 | with_tag2` and othersuch) as you need and filter them to your hearts' content, without having to instantiate Tag all the time (which you can of course do as well).
I found [snippet #1016](http://www.djangosnippets.org/snippets/1016/) while looking for a way to add a button to the top of an admin change form, and it didn't work. I found that it used the old admin, so I updated it to django 1.1.1
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.