This replaces the html select box for a foreign key field with a link to that object's own admin page. The foreign key field (obviously) is readonly.
This is shamelessly based upon the [Readonly admin fields](http://www.djangosnippets.org/snippets/937/) snippet. However, that snippet didn't work for me with ForeignKey fields.
from foo.bar import ModelLinkAdminFields
class MyModelAdmin(ModelLinkAdminFields, admin.ModelAdmin):
modellink = ('field1', 'field2',)
A simple backend which allows you to login with either an email address or a username.
It should be combined with another backend for checking permissions:
AUTHENTICATION_BACKENDS = (
'myproject.accounts.backends.EmailOrUsernameModelBackend',
'django.contrib.auth.backends.ModelBackend'
)
Django administration provides three buttons for submitting the currently edited object. Each of them has a unique name and depending on the name that is sent to the server, the specific action is performed. I see this as an ugly solution and prefer to have a choice field in the form which would render as submit buttons with different values. Then the values would be checked instead of the names. Therefore, I created the `MultipleSubmitButton` widget. When `<input type="submit" value="Go" />` is used, the value sent to the server always matches the text on the button, but if `<button type="submit" value="go">Go</button>`, the value and the human representation might differ.
To use the `MultipleSubmitButton` widget, pass it to the widget parameter of a `ChoiceField` like this:
SUBMIT_CHOICES = (
('save', _("Save")),
('save-add', _("Save and Add Another")),
)
class TestForm(forms.Form):
do = forms.ChoiceField(
widget=MultipleSubmitButton,
choices=SUBMIT_CHOICES,
)
When you print `{{ form.do }}` in the template, the following HTML will be rendered:
<ul>
<li><button type="submit" name="do" value="save">Save</button></li>
<li><button type="submit" name="do" value="save-add">Save and Add Another</button></li>
</ul>
When you submit this form and check the validity of it, `form.cleaned_data['do']` will return "save" or "save-add" depending on the submit button clicked.
I will change a model form widget attribute without define the complete field. Because many "meta" information are defined in the model (e.g. the help_text) and i don't want to repeat this.
I found a solution: Add/change the widget attribute in the __init__, see example code.
A simple script that I have put in my Django applications directory to fetch the latest application code from git and svn.
For example, your directory structure might look like so:
django-apps/
django-tagging/
django-pagination/
django-registration/
django-threadedcomments/
django-mptt/
update_apps.py
Where update_apps.py is the source of this snippet.
To run, simply execute:
# python update_apps.py
And the script will iterate through all of your apps and update them to the latest version.
This is intended as an alternative to http://www.djangosnippets.org/snippets/155/
Put this in your own cache.py and import it instead of django.core.cache and use it the same way. We left out the "add" function but it shouldn't be too hard to make if you want it.
From the above post: "The purpose of this caching scheme is to avoid the dog-pile effect. Dog-piling is what normally happens when your data for the cache takes more time to generate than your server is answering requests per second. In other words if your data takes 5 seconds to generate and you are serving 10 requests per second, then when the data expires the normal cache schemes will spawn 50 attempts a regenerating the data before the first request completes. The increased load from the 49 redundant processes may further increase the time it takes to generate the data. If this happens then you are well on your way into a death spiral
MintCache works to prevent this scenario by using memcached to to keep track of not just an expiration date, but also a stale date The first client to request data past the stale date is asked to refresh the data, while subsequent requests are given the stale but not-yet-expired data as if it were fresh, with the undertanding that it will get refreshed in a 'reasonable' amount of time by that initial request."
Allows getting the rendered content of a specific block tag. Useful if you want to send just a part of a template back for an AJAX request. Works for arbitrary template inheritance, even if a block is defined in the child template but not in the parent.
Example:
In `test1.html`:
{% block block1 %}block1 from test1{% endblock %}
{% block block2 %}block2 from test1{% endblock %}
In `test2.html`:
{% extends 'test1.html' %}
{% block block1 %}block1 from test1{% endblock %}
And from the Python shell:
>>> from django.template import loader, Context
>>> from template import render_block_to_string
>>> print render_block_to_string('test2.html', 'block1', Context({}))
u'block1 from test2'
>>> print render_block_to_string('test2.html', 'block2', Context({}))
u'block2 from test1'
UPDATE: See also [zbyte64](http://www.djangosnippets.org/users/zbyte64/)'s implementation in snippet [#942](http://www.djangosnippets.org/snippets/942/)
Sometimes the order of the fields you get from a model needs to be adjusted when displaying its modelform. If it's just a few fields you can do it in the template, but what if you want to iterate over the form?
The fields are stored in a SortedDict, so you can change the order in the __init__ of the form. A bit clunky, yes.
If you try to use multiple inheritance with a modelform (to mix in some fields from an already existing form class for example) you'll get the following rather terrifying error:
> "Error when calling the metaclass bases metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases"
The solution is to first create the ModelForm, then create a NEW class that inherits from both the ModelForm and the form you want to mixin, then finally apply the recipe from here: [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/204197](http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/204197)
**Paginator TemplateTag**
TemplateTag to use the new Paginator class directly from a template.
The paginate template tags take the following options:
1. list or queryset to paginate
2. number of pages
3. [optionaly] name of the Paginator.Page instance; prefixed by keyword 'as'
4. [optionaly] name of the http parameter used for paging; prefixed by keyword 'using'
If you want to specify the parameter name with the keyword 'using' you must use the 'as' keyword as well. The default name of the paging variable is "page" and the paginator (the class that knows about all the pages is set in the context as "page_set". This follows the naming scheme of the ORM mapper for relational objects where "_set" is appended behind the variable name.
Usage, put the following in your template:
{% load paginate %}
{% get_blog_posts blog_category as posts %}
{% paginate posts 10 as page using page %}
<ul>
{% for post in page.object_list %}
<li>{{ post.title }}</li>
{% endfor %}
</ul>
<div>
{% if page.has_previous %}
<a href="?page={{ page.previous_page_number }}">previous</a>
{% endif %}
<i>{{ page.number }} of {{ page_set.num_pages }}</i>
{% if page.has_next %}
<a href="?page={{ page.next_page_number }}">next</a>
{% endif %}
</div>
The templatetag requires the request object to be present in the template context. This means that you need 'django.core.context_processors.request' added to settings.TEMPLATE_CONTEXT_PROCESSORS list or otherwise make sure that the templatetag can access the request object.
Comments are appreciated.
This middleware makes the admin error emails a lot more informative: you get the same HTML response that you get with `DEBUG=True`.
It uses the base class defined in [#638](http://www.djangosnippets.org/snippets/638/).
You will probably want to apply the patch for [#6748](http://code.djangoproject.com/ticket/6748) to help avoid slowdowns caused by unintentional database queries. As the ticket (and django-developers thread) notes, it isn't foolproof; you may still find this executing database queries.
You're looking at the top-rated snippets currently on the site; if you'd like to contribute, sign up for an account and you'll be able to rate any snippet you see.