This might be a bit cludgy. But the idea is to extend model definition with mixins that can help with defining standard views. So defining a new model as inheriting from Model and All, would allow automatic definition of /get /post type accessors.
Complex of tags and filters for easy replacement of text with alternative font faces. For browsers, who doesn`t support it by themselves. Templatetag code and documentation at [GitHub of django-headline](http://github.com/SkAZi/django-headline).
A number of people have kindly posted snippets on how to use pdb/ipdb with django. However, this only works when running the django development server. I thought it would be nice to have a trace() command that would turn into a no-op when the development server is not running, so you wouldn't have to worry about leaving trace() commands in your code if you want to quickly test with mod_wsgi or mod_python. The code above attempts (on Posix-like systems) to determine if the development server is running (by quickly checking if "manage.py runserver" is in the process list), and sets a DJANGO_SERVER setting appropriately. Then when you import the trace() method, it is defined as set_trace() if DJANGO_SERVER is True, or a no-op if DJANGO_SERVER is False. When you hit the trace() in pdb/ipdb, enter "u" to go up to the calling trace() statement.
If you have another application in the same Apache virtual host and also want to use the authentication from Django - this might help. It uses the Django cookie - so it will not work in another Apache virtual host.
Is an updated way of splitting contents for a token, it does the split, but fixes the list.. EX: From a tag call like this: {% partial "partials/template.html" %} usually you get: ['partial','"partials/template.html"'] notice the " double quotes fixes it with: ['partial','partials/template.html'] takes out the " quotes
A quick and dirty hack for composite indexing if you need it. Drop this into a models.py or some other place where it'll be loaded along with the rest of Django on start up. Then add an _index_together tuple specifying the fields you want a composite index on.
Getting a new ID according to the content type.
A python implementation of the old MySQL PASSWORD() function. This is insecure. There is a reason MySQL changed this in version 4.1. Use it only if you have to!
This snippet provides a uuid field for models, improving on the work in http://www.djangosnippets.org/snippets/335/
The "testdata" tag allows you to inline test data into your templates, similar in spirit to Python doctests. There are two sections--the test data and the actual template to be rendered. In non-test mode your template renders normally from whatever views call it, and there is very little overhead to skip over the test data section (happens at parse time). Here are the goals: 1. Provide convenient way to test templates without surrounding infrastructure. 2. Make templates be self-documenting in terms of expected data. 3. Allow insertion of test data at arbitrary places in template structure. Hello-world looks like this: {% load handytags %} {% testdata %} { 'greeting': 'Hello', 'planet': 'World', } {% --- %} {# This is where the actual template begins #} {{ greeting }} <b>{{ planet }}</b> {% endtestdata %} To invoke it, set up urls.py with something like this: url(r'^testdata/(?P<template_path>.*)', test_template) def test_template(request, template_path): context = {'testdata_use': True} # put request vars into context to help choose # which test data we want to render for field in request.GET: context[field] = request.GET[field] return render_with_request(template_path, context, request) Then call: http://127.0.0.1:8000/testdata/hello_world.html Features: 1. The testdata tag's rendering will expose missing variables a bit more aggressively than Django normally does. 2. You have the full power of the template language to set the test data (which ultimately gets eval'ed as a Python expression). 3. As mentioned above, the tag is mostly unobtrusive. Limitations/caveats: 1. Right now the only data format I support is pure Python, but the tag could be modified pretty easily to support JSON or YAML. 2. The VerboseContext class is pretty heavy-handed--I really just want a hook into Django to tell it to render a section with more strictness about variables. Suggestions welcome. 3. You can put the testdata tag pretty much anywhere, but the normal rules apply...for example, if you are in a template that has the extend tag, you'll want to put the testdata tag in individual blocks.
Default to a static template. **Example:** urlpatterns = patterns('', ... # this rule SHOULD BE the last one (r'^(?P<template>[a-z-_/]+/?)?$', 'myproj.apps.myapp.views.static_template'), )
Renders a view to an email. You need to set all of the required settings for email support.
Get the referer view of a request. **Example:** def some_view(request): ... referer_view = get_referer_view(request) return HttpResponseRedirect(referer_view, '/accounts/login/')
A template filter which wraps imagemagick's `convert` command. The filter acts upon a source image path, and returns the filtered image path. usage: {{ source_path|convert:"-resize 64x64\!" }} The filter parameter is the processing arguments for an ImageMagick 'convert' command. See e.g. http://www.imagemagick.org/Usage/resize/ Every image created is saved in a cache folder. This code does not handle removing obsolete cached images. If the filtered image path exists already, no image processing is carried out, and the path is returned.
Let's say you have a dataset and you want to render a page with sections/subsections/subsubsections down to some arbitrary depth and with arbitrary keys. For example, you might want to show cars broken out by year/price_range or price_range/year or price_range/manufacturer/model. The outliner template tag allows you to support multiple breakdowns of your data in a DRY sort of way. In order to use it, you supply four things: 1. a template for surrounding each subsection (think turtles all the way down) 2. a queryset (really anything iterable) 3. sectionizer dictionary/objects (see sample code, you must supply key_method) 4. inner html to render the lowest subsections The template provides the following: 1. It recursively uses each of your sectionizers' key methods to divvy up data sets. 2. It surrounds each section with templates of your choosing. 3. It renders the inner template for all the "leaf" elements of your tree. 4. It supplies some handy context vars for things like depth and outline ids. What this is not: 1. this is not for arbitrary tree data--think of the tree as fixed depth 2. this is not as simple as the regroup tag--if you have a concrete organization to your data, you should keep it simple and hand-code your templates