Removed for now... Not sure where to share new Ellington snippets due to the gray-area of it being proprietary. It's an awesome package but it's hard to find any good help with Django 91 code. Good luck ellingtoners!
Removed for now... Not sure where to share new Ellington snippets due to the gray-area of it being proprietary. It's an awesome package but it's hard to find any good help with Django 91 code. Good luck ellingtoners!
A templatetag to add [Gravatar](http://www.gravatar.com/) support for [Django comments](http://docs.djangoproject.com/en/dev/ref/contrib/comments/ "Django Comments"). Based on [this snippet](http://www.djangosnippets.org/snippets/772/) but works for everyone who comments even if they are not a registered user.
This code sets the default sites for a sites ManyToMany property to `Site.objects.all()`, which makes sure you don't have to bother setting it for each item on a site. This could easily be changed to `Site.objects.get_current()` to use the current site as default.
A companion to [Cache Decorator](http://www.djangosnippets.org/snippets/1130/).
If you need two values for validation, you can't use clean_value_a() since it is undefined if value_a or value_b gets cleaned first. This little helper lets you add ValidationErrors to fields instead of \__all\__. Related [Ticket 5335](http://code.djangoproject.com/ticket/5335).
this snippet provides a class that can be subclassed for creating views that retain state between requests, you can read more here http://code.google.com/p/django-stateful/ your comments are welcome!
This snippet provides two view classes. The two reason I wanted to write this are, 1) Not have to import all the boilerplate code for each view and 2) so I could have the same URL handle loading a persons profile, or handle an OpenID login request without having to write two separate views. (Yes I know it isnt to hard to write my view, check the header and pass it off to the proper handler view, but I think it looks better code wise to have the handler methods all in one class) The first one is just for normal views conveniently called *View*. The *View* class that lets you do at least 90% of what you can do in a normal view function, but without having to import all the normal boilerplate code first since this class wraps methods around most if not all the *HttpResponse* types. The second class *StatefulView* maintains its state across page loads This is especialy useful for ajax type calls where you wish to maintain some form of state while the user is doing something but do not wish to make DB calls and do not wish to polute the session with trivial things **Note:** On my system it maintains state across browsers and computers as it is not tied to the session, BUT for this to happen all requests must be handled by the same proccess. So requests going to a differing process with not have the state maintained.
To make all scripts relocatable. The layout of my project is: /some/path/myproject/ /some/path/myproject/some_script /some/path/myproject/some_other_script /some/path/myproject/set_paths.py /some/path/myproject/setttings.py /some/path/myproject/lib/ # some external libraries/apps checked in with my project. /some/path/myproject/myapp/ # my apps etc. This way myproject folder can be moved anywhere on the file system, and calling right path, settings.py is used.
This is slight improvement over [Paginator|Snippet 73](http://www.djangosnippets.org/snippets/73/). That used to not work properly if querystring already contains other parameters, like search result page. website/paginator.html: <br /><center> <span class="lbottom"> {% if has_previous %}<a href="{{ path }}page={{ previous }}"><< Previous </a>{% else %}<span>Previous </span>{% endif %} {% if show_first %}<a href="{{ path }}page=1">First </a>{% endif %} {% for page_no in page_numbers %} {% ifnotequal page_no page %} <a href="{{ path }}page={{ page_no }}">{{ page_no }} </a> {% else %} {{ page_no }} {% endifnotequal %} {% endfor %} {% if show_last %}<a href="{{ path }}page={{ pages }}">Last </a>{% endif %} {% if has_next %}<a href="{{ path }}page={{ next }}">Next >></a>{% else %}<span>Next </span>{% endif %} </span> <br /></center>
This exception is util when you want to raise an exception but want its message be shown as a message to the user, with no error 500 or 404 pages. To use it, just append the middleware in the MIDDLEWARE_CLASSES setting and raises HttpMessage when necessary.
I use this as the FastCGI script for authorizers with lighttpd (though I guess it should work with little change on any other webserver supporting FastCGI). I point it to the same Django project/settings as the normal responder script. As I use it to gate access to pages not served by Django, I can include those non-Django URLs in the main urls.py, connected to special authorizer view functions (in another snippet). The two key parts of the script, compared to the equivalent one for Django in the normal FastCGI Responder role, are: 1. Pass the FCGI_AUTHORIZER as the role to WSGIServer 2. Generate a PATH_INFO variable from the REQUEST_URI (FastCGI authorizers aren't given PATH_INFO, but Django needs that to match against the URLconf.)
This is a basic view for a FastCGI authorizer against the Django auth. The idea is to return either a blank response with REMOTE_USER set on success, a forbidden response for failure, or a redirect to a login page when no user is logged in. I use this view for a Trac instance running on the same (lighttpd) server as Django. lighttpd is set up to use Django as a FastCGI authorizer (using snippet 1149) for the Trac URLs instead of using basic/digest HTTP authentication, so Trac has the same users as Django.
Format Number Based on Regular Expression **Examples** >*{{.1234|regex_comma_number:'%.4f'}} >*'0.1234' >*{{100|regex_comma_number:'%i'}} >*'100' >*{{ 234.5678|regex_comma_number:'%.4f'}} >*'234.5678' >*{{234.5678|regex_comma_number:'$%.4f'}} >*'$234.5678' >*{{1000|regex_comma_number:'%i'}} >*'1,000' >*{{1234.5678|regex_comma_number:'%.4f'}} >*'1,234.5678' >*{{1234.5678|regex_comma_number:'$%.4f'}} >*'$1,234.5678' >*{{1000000|regex_comma_number:'%i'}} >*'1,000,000' >*{{1234567.5678|regex_comma_number:'%.4f'}} >*'1,234,567.5678' >*{{1234567.5678|regex_comma_number:'$%.4f'}} >*'$1,234,567.5678' >*{{-100|regex_comma_number:'%i'}} >*'-100' >*{{-234.5678|regex_comma_number:'%.4f'}} >*-234.5678' >*{{-234.5678|regex_comma_number:'$%.4f'}} >*'$-234.5678' >*{{-1000|regex_comma_number:'%i'}} >*'-1,000' >*{{-1234.5678|regex_comma_number:'%.4f'}} >*'-1,234.5678' >*{{-1234.5678|regex_comma_number:'$%.4f'}} >*'$-1,234.5678' >*{{-1000000|regex_comma_number:'%i'}} >*'-1,000,000' >*{{-1234567.5678|regex_comma_number:'%.4f'}} >*'-1,234,567.5678' >*{{-1234567.5678|regex_comma_number:'$%.4f'}} >*'$-1,234,567.5678'`
Django's templates don't provide much in the way of arithmetic: there is an "add" filter and that is about it. Even if sub, mult and div filters are implemented, it is difficult to chain filters while preserving some complicated expression, such as ((x+3)4-(2-y)/12.75). However, this expression can be converted into Reverse Polish Notation: x 3 + 4 * 2 y - 12.75 / - which is just a sequence of operations (push-value or apply-operator) and can be chained. To use these filters, first create a new stack for the expression with name|stnew (pass it some locally unique value). To push a number (or template variable) onto the stack, call name|stpush:number (note that you have to tell stpush the name of the stack to push onto). To pop, call name|stpop. To perform an operation, call name|st[add,sub,mult,div,mod]:number. All numbers are integers if they look like integers, or floats otherwise (integers are turned into floats upon division if they need to be). All of these functions return the name of the stack so that they can be chained. When the calculation is finished (i.e. the answer is at the bottom of the stack) call name|stget to retrieve it. Example (this was used to calculate an inline CSS value: `left: {{ forloop.counter|stnew|stpush:res.stwkday|stpush:"9.35"|stmult|stpush:res.get_item_left|stpush:"2.75"|stadd|stadd|stget }}em;`