This is an example of how you change a ChoiceField select widget into a hidden field if the right GET variable is passed. In this example code it would change the select widget into something like the following if something like "?d=3" was passed. `<p><label for="id_designation">Designation</label>Designation Option<input type="hidden" name="designation" value="3" id="id_designation" /></p>`
A better way of dealing w/profanity - disemvowel it! From [Wikipedia](http://en.wikipedia.org/wiki/Disemvoweling), "disemvoweling is a technique used to censor unwanted postings such as spam, internet trolling, rudeness or criticism and yet maintain some transparency, both of the act and the underlying word." Credit: Boing Boing Example: This original sentence: In the fields of Internet discussion and forum moderation, disemvoweling (also spelled disemvowelling) is the removal of vowels from text. would be disemvowelled to look like this: n th flds f ntrnt dscssn nd frm mdrtn, dsmvwlng (ls splld dsmvwllng) s th rmvl f vwls frm txt. Usage: body_input = form.cleaned_data["body"] body_input = disemvowel_profanity(body_input)
Many of my projects heavily depend on other non-django projects to create the databases. To simplify setting up a test environment, I modified the simple test runner so that it will treat all models as managed. This will also allow for easier test set up against models that point to views. You can directly populate the view with the specific data needed for the tests, instead of populating (potentially) several models.
A filter that changes a preparsed date from [Ultimate Feedparser](http://www.feedparser.org/) to a regular datetime instance. Now you can -for example- pass a feed parsed by feedparser to a template and do this: {% for item in feed.entries %} Title: {{ item.title }}<br /> Date: {{ item.updated_parsed|feedparsed|date:"Y-m-d" }} {% endfor %}
If you're using [Django granular permissions](http://code.google.com/p/django-granular-permissions/), this templatetag may be useful. It enables you to check permission in templates, as mentioned in the code: {% has_row_perm user object "staff" as some_var %} {% if some_var %} ... {% endif %} To be used in `if` statements, it always saves the result to the indicated context variable. Put the snippet in row_perms.py in yourapp.templatetags package, and use `{% load row_perms %}` at your template.
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.
This set of handlers allow one to isolate requests based on the method posted. Normally, in a view, we would do checks for request.method value and update the resource accordingly. This makes the view code pretty messy. So one way to avoid these check each time is to have a handler method (resource_handler above), that checks for the method parameter and dispatches to the handler withe the prefix <method>_handler_<suffix>. This also has the advantage of grouping related actions in a particular class. At the same time a new instance of the request handler is not created on each request (as with the google appengine handler?). Yet another advantage is by making the handler methods as class methods, the handler classes can be inherited to add further functionality to a resource "group. The disadvantage however is the inability to restrict access to a handler method to only particular methods. Eg above the "r'obja/(?P<id>[^\/]+)/delete/" would map to the delete_handler_objects if themethod was "delete" and post_handler_objects if the method was "post". However this can be worked with a different suffix passed to the handler_params method. Infact setting the suffix to "objects_delete" would result in a "delete_handler_objects_delete" handler on delete method and a Http404 on all others. Another inconvinience is the inability to detect a view handler by simply inspecting the url patterns. However, this information is carried within the handler_suffix and handler_class parameters which may infact provide greater insight into the semantics around the view handlers. Needless to say, this easily extends rest based accesses. Would greatly appreciate feedback and improvements.
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 {% mailto %}{% endmailto %} template tag that requires an e-mail destination and optionally accepts subject, cc and bcc. It will then wrap whatever is within the tag in an `<a href="mailto:..."> </a>` HTML tag. See the docstring in the code for the {% mailto %} usage and some examples. You will need to load this template tag to your template. You can find detailed instructions [here](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#code-layout). But in a nutshell: 1. Create a templatetags package (meaning a directory with a __init__.py file in it) on the same level as your application's model.py 2. Put the code for this tag in a module (example: extra_tags.py) 3. On your template use {% load extra_tags %} -- note: the app where the templatetags package was created needs to be in INSTALLED_APPS 4. Use {% mailto user.email 'You subject here for {{user.get_full_name}}' %}blah{% endmailto %} This is my first django template tag. I am also NOT tremendously experienced with Python. Criticism and corrections are more than welcome.
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.
Sometimes you just need to count things (or create unique-for-your-application IDs). This model class allows you to run as many persistent counters as you like. Basic usage looks like this: >>> Counter.next() 0 >>> Counter.next() 1L >>> Counter.next() 2L That uses the "default" counter. If you want to create and use a different counter, pass its name as a string as the parameter to the method: >>> Counter.next('hello') 0 >>> Counter.next('hey') 0 >>> Counter.next('hello') 1L >>> Counter.next('hey') 1L >>> Counter.next('hey') 2L You can also get the value as hex (if you want slightly shorter IDs, for use in URLs for example): >>> Counter.next_hex('some-counter-that-is-quite-high') 40e
Simple client to get some stats from memcached.
The code posted here adds "elif" functionality to the [smart if snippet 1350](http://www.djangosnippets.org/snippets/1350/). To use the snippet first follow the instructions for installing smart_if, then swap in the method shown on the left for the original smart_if method. You'll need to keep all the supporting classes from the original implementation, of course. You can use it like this: {% if 0 %} {% if 1 %} Hello Venus {% else %} unexpected {% endif %} {% elif 0 %} Hello Earth {% elif 0 %} Foo {% else %} Hello Mars {% endif %} The code is compatible with original smart_if classes as of June 2009, and the use of "__contains__" in the Enders class relies on the current implementation of Parser.parse, which says "if token.contents in parse_until:" in the one place it uses the parse_until parameter, which seems like stable code to me. The code works by recursively creating SmartIfNodes for the elif clauses.
This snippet is a variation on snippet 1550 that works with the Eclipse pydev plugin. This allows you to set up a breakpoint anywhere in your template code, by simply writing {% pydev_debug %}. Be sure to launch pydev in debugger mode first. Once you're in the debugger, you can explore the stack and quickly find which context variables are set. This can be especially useful inside for loops, etc., where you want to see how the templating code is mucking with the context. This can also be useful when your templates are ultimately rendered by code that might not understand very well, such as generics.
The code shown allows you, in GeoDjango, to reduce the number of points in your polygons. It helps reduce storage needs and makes queries run faster, at the cost of some precision. It provides a variation on the simplify() method that comes with the GEOS API, allowing you to specify a number of points instead of a distance tolerance. It is set up as a management command so that you can run it with python manage.py. See the django docs for how to set that up. The example shown assumes a table called CountyBorders with fields "name" and "mpoly." It should be straightforward to adapt it for your needs. Look at the first three lines of the simplify() method in particular for customization. The rest of the code is pretty generic, and it should run fast enough in a one-time batch process for most needs. The algorithm tries to keep the 75 points that provide the most definition for the shape. Each point in a polygon defines a triangle with its immediate neighbors. If that triangle has no area (the degenerate case), it is a midpoint on the segment between its neighbors and adds no value whatsoever. This principle is extended to say that the larger the triangle, the more value the point has in defining the shape. (You can find more refined algorithms, but this code seems to work fine by visual inspection.)