Settings file switcher
Changes settings file according to server hostname.
- settings
Changes settings file according to server hostname.
**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.
Add delete button on admin control panel to make delete as easy
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.
This example shows how you can easily limit the objects in the admin by specifying which Manager the admin should use. I haven't seen this documented anywhere (perhaps I've missed it), but it's proven extremely useful to me. The example here will limit objects to those that are attached to the current Site, but you can use any Manager you want (for example, a Manager that shows only published Articles). Finally -- not that I'm suggesting this -- but you *could* combine this with the ThreadLocals trick to show only objects that have been created by that user.
I like to keep all local settings files in my versioning repository. The way I differentiate between them is by querying the hostname of the local machine. I've got a host_settings folder with local settings files. Notice that the local settings file names go by a convention where '.' is replaced with underscores. Example: host_settings/local_machine_tld.py
Based on the discussion at Empty Thoughts (http://blog.michaeltrier.com/2007/8/6/age-in-years-calculation) I built a quick and dirty custom filter. Save this as a file in your "templatetags" folder. I called mine "calculate_age.py" and then in your template "{% load calculate_age %}" then use it, "{{ object.birthdate|age }}"
You need htmldoc, rst2html, the Python Imaging Libraray, BeautfiulSoup and spoon. The Debian/Ubuntu-packages are called htmldoc, python-docutils, python-imaging and python-beautifulsoup You can get spoon.py http://beautifulspoon.googlecode.com/svn/trunk/spoon.py To create the pdf files you have to call the script from django_src/docs Here is an example output: http://henning.cco-ev.de/django/essential.pdf
This is an example how to use relative paths in settings file, but still keep settings readable.
link and img are both HTML construction helpers. Good idea to use these helpers if your html don't fit into templates.
This script will reload apache when any modifications are detected in a folder - useful only if the development server or mod_python's reload does not suit your needs for testing. It requires Linux 2.6.13+, Python 2.5, and the [development version of pyinotify](http://seb.dbzteam.com/pages/pyinotify-dev.html).
Replaces <code> blocks with syntax highlighted code. Use CSS to actually get the colours you want, look at pygments documentation for extracting css for various styles. This snippet has the advantage of falling back on <pre> if anything goes wrong, and attempting to guess the syntax of code, falling back on python.
You can switch boolean fields in the admin without editing objects Usage: ` class News(models.Model): # ... pub = models.BooleanField(_('publication'),default=True) # ... pub_switch = boolean_switch(pub) class Admin: list_display = ('id', 'pub_switch') ` Thanks for [svetlyak](http://www.djangosnippets.org/snippets/398/).
Usually, you can add links in the admin using such code: class Pingback(models.Model): #... target_uri = models.URLField( _('Target URI')) #... def admin_target(self): return '<a href="%(targ)s">%(targ)s</a>' % {'targ': self.target_uri} admin_target.short_description = _('Target URI') admin_target.allow_tags = True #... class Admin: list_display = ('id', 'admin_target') But when you have two or more url fields, such approach becomes to expensive. Follow the DRY principe and use my code in such way: # Just add this line instead of the ugly four lines **def blabla** admin_target = link('target_uri', _('Target URI'))
The rationale behind this decorator is described in django-users google group. Usage: === urls.py === urlpatterns = patterns('', (r'^', include('apps.app1.views')), (r'^app2', include('apps.app2.views')), ) === apps/app1/views/__init__.py === @url(r'^index/$') def index(request): ... @url(r'^news/$') def news(request): ... urlpatterns += include_urlpatterns(r'^members', 'apps.app1.views.members') === apps/app1/views/members.py === @url(r'^profile/$) def profile(request): .... @url(r'^secure/$) def secure(request): ... @url(r'^path1/$', '^path2/$') # you can specify several patterns def multipath_view(request): ... def helper(): # easily distinguishable - no @url! ... Summarizing, the benefits are: * no more creating and supporting urlpattern maps (less files, less code, more DRY) * have the url associated with a view in-place * easily see if a function is a view * fully compatible with other chained decorators