A simple client to get some info (NOT values...) from memcached

Simple client to get some stats from memcached.

Counter model - run multiple persistent counters

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

A smart trace() command

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.

Soft Timeout Middleware

This middleware implements a "soft timeout". This means the admin is sent an email whenever a page time exceeds a certian value. It is intended to run on production servers to inform the admin of any pages which are performing slowly.

Template tag to create mailto links with options

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.

Text replacement with alternative font faces

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).

Using class methods as views

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.

Custom CSS class in Form with template tag filter

A lot of times we need to insert a specific **CSS class** into a Form instance for it to be rendered in the template. The current method is to specify the CSS class in the Python code through the form field widget. But it would be easier for the designer to be able to specify the CSS class in the template directly. For example rather than doing this in your Python code: 'name = forms.CharField(widget=forms.TextInput(attrs={'class':'special'}))` You can do this in your template: `{{ form.name|cssclass:"special"}}` This template filter only works with Form Field instance.

Automating URLs

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.

Format Haystack's result with a sprat template

Templatetag for granular permissions

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.

Dynamically add inlines

These functions use JQuery to dynamically add new entries for stacked or tabular inlines on a change form. To enable it, change the parent model to include this Javascript as well as JQuery. Here's an example: class MeetingAdmin(admin.ModelAdmin): inlines = [MeetingDonationInline, MeetingExtraInline] class Media: js = ["/media/jquery-1.3.2.min.js", "/media/dynamic_inlines.js"]

Testing with unmanaged models

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.

Ensure submitted slugs do not conflict with existing resolvable URLs

This code overrides the existing RegistrationForm in django-registration and adds a new validation step. In this step, the username (my example slug) is compared against all the existing URLs that the application currently resolves and, if it *does* successfully resolve, throws a validation exception. This indicates that the username chosen would be overriden (or, if you wrote your urls.py file badly, would override) an existing URL already recognized by your application. A much longer explanation can be found at [Dynamic names as first-level URL path objects in Django](http://www.elfsternberg.com/2009/06/26/dynamic-names-as-first-level-url-path-objects-in-django/).

Profanity Function (Disemvowel)

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)