Counter tag. Can be used to output and increment a counter. For usage, see docstring in the code. This is the first complete tag that I've implemented, I hope that there are no bugs and that it's thread safe.
Inspired by [http://www.djangosnippets.org/snippets/712/](YUI Loader as Django middleware) This loads in css and javascript files where you want them (usually in the head) - but allows you to put them anywhere in your code - i.e. in a TemplateTag. so your head code will look like this: ` <head> ... <!-- HEAD_init --> ... </head> ` then somewhere in your templates you can load in javascript or css files like so: ` <!-- HEAD_include myfile.js myotherfile.css --> ` It automatically checks if you've already included the files, and only puts them in once. It automatically figures out if its a javascript or css file by the file name - If you have an irregular filename (i.e. a google maps api script url) you can force it by using either of the following tags: ` <!-- HEAD_include_js [my javascript file] --> <!-- HEAD_include_css [my css file] --> ` Or you can write inline code to get rendered in the head: ` <!-- HEAD_render <script> someJavascriptCall(); </script> --> ` Todo: make it compress the js into one file...
Building on [jcroft's snippet](http://www.djangosnippets.org/snippets/17/), here's a slightly more advanced version which has two filters, one for basic text and the other for html snippets. Usage is like so: <h2>{{ blog_entry.headline|escape|widont }}</h2> {{ blog_entry.html|widont_html }} On top of Jeff's reasons for using these filters, they are important because they help keep one of [God's commandments](http://www.ebible.com/bible/NIV/Exodus+22%3A22). ;)
This decorator does automatic key generation and simplifies caching. Can be used with any class, not just model subclasses. Also see [Stales Cache Decorator](http://www.djangosnippets.org/snippets/1131/).
This class runs a django test server in another thread. This is very useful for e.g. selenium integration. Simple to integrate into django test framework. Usage: server = TestServerThread("127.0.0.1", "8081") server.start() # Run tests e.g. req = urllib.urlopen("http://127.0.0.1:8081") contents = req.read() server.stop() ps. I don't actually double space my code :). Not sure whats up with that!
I needed to overwrite files on update (not create new ones) but also a validation which would prevent to upload 2 files with the same name. The CustomCheckFiled triggers a validation passing the filename and model instance. If the validation returns false, the validation error_message will be displayed in admin. The OverwriteStorage is needed because the default storage alters the name if such name already exists. Enjoy.
Template filter to mark-up individual form fields. Usage : In template - {% load form_custom %} then for a form field - {{ form.field|form_row:"default" }} for default wrapper or - {{ form.field|form_row:"lbl_cls=some_class_name&reqd=no" }} to pass option args seperated by & Optional args are :- wrapper_cls - override default field wrapper div class name error_cls - override default field error div class name lbl_cls - override default label_tag div class name label - yes/no default is yes - output label_tag reqd - yes/no default is yes - marks up required fields as bold with label ending with * See code for all default args.
see comment block for example.
We currently use two-level tuples to specify choices of a field in models or forms. But, because it has only (value, verbose name) pair, the readability is bad whenever we indicate a specific choice value in our Python codes. So I made a small class that does "magic" for this: A Named Enumeration. Instead of `myobj.status == 0`, use `myobj.status == STATUS.UNREVIEWED`, for example.
If you have a model with foreign key to User, you can use this manager to show (i.e. in admin interface) only objects, that are related to currently logged-in user. Superuser sees all objects, not only his. Requires: [ThreadlocalsMiddleware](http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser)
Simple wrappers around the new class-based generic views (introduced in Django 1.3) that also check permissions. **Example Usage** *(views.py)*: from mymodule import RestrictedListView, RestrictedUpdateView class MyListView(RestrictedListView): model = MyModel class MyUpdateView(RestrictedUpdateView): model = MyModel and so on for Create and Delete.
**Your model:** class TicketItem(models.Model): hours = models.DecimalField(decimal_places=2, max_digits=6) day = models.DateField() order = models.ForeignKey(Order) tickets = models.ManyToManyField(Ticket) Now you want to auto save m2m fields in your forms.TicketItemCreateForm: 1. inherit from m2mForm-Class 2. define m2m_field(s) **Example:** class TicketItemCreateForm(m2mForm): m2m_field = 'tickets' class Meta: model = models.TicketItem
you have a multilingual site and need to change languages in admin. Previously this was easy in the site itself and more difficult in admin. Now it is dead easy. Set up your languages in settings.py. Make a directory called 'admin' in your templates directory, copy ~/django/contrib/admin/templates/base.html to that directory. Add the following code (below breadcrumbs is a good place) this will give you a switcher for all installed languages. You would need to refresh the browser on changing the language.
This snippet is greatly inspired by [@jlorich](http://djangosnippets.org/users/jlorich/)'s useful [#2436](http://djangosnippets.org/snippets/2436/). The main difference is that I wanted to choose the names of my URL params instead of being forced into naming them "value1", "value2", etc. When reversing the URL you have to remember that the kwargs aren't friendly. By using the same names in the `filters` list, you don't have to change the way your otherwise write the URL pattern. Also it's clear throughout how you'll be filtering the QuerySet. The other change I made was "erroring early". This avoids running the QuerySet all over again inside `object_detail()` just to have it raise an exception we could have caught the first time.
This view acts as an extension to the object_detail generic view in django.views.generic.object_list. The standard generic view can only filter the queryset by object_id or slug; this view allows you to filter by any parameter you like, as well as multiple parameters. The usage is the same as the standard object_detail view except that you must also give the parameter 'filters', which should be an array of what you would like to filter the url values as, and instead of 'slug' or 'object_id' as the regex parameter in the URL, use 'value1', 'value2', etc. Example: If you have a list of companies, each with multiple branches, you may want a branch details page. A URL for this may look as follows: http://www.mysite.com/company/company-slug/branch-slug/. To implement this simply use the urlpattern example give,