This is a small addition to the mako template processing plugin for django that allows you to use the unit test framework with mako templates. To install, put the code into a file on your python path, and add the python path to your settings.py file. For example, if you install the code at
/usr/lib/python2.5/site-packages/mako_django/test_integration.py
you would add the following line to settings.py:
TEST_RUNNER="mako_django.test_integration.run_mako_tests"
This code will still call all of the normal test code, it just adds the mako template handler onto the list of things that are monitored.
A Textarea widget which appends basic Textile formating instructions in the same way Basecamp's Writboard product displays some basic helper markup alongside the edit area.
This script generates an [GraphViz](http://www.graphviz.org/) graph of your database structure from your django models.
See the usage if the file underneath the license.
This is a very small, simple piece of code, but essential for using fields of type 'money' on MS SQL Server, through FreeTDS. This took me quite some time to hunt down, as get_placeholder() is in fact an undocumented feature.
**Example:**
class MyModel(models.Model):
price = MoneyField()
If you want to add an fckeditor for every vLargeTextField (the input class used by models.TextField) you can use this javascript.
you can load that in all admin pages overriding templates/admin/base_site.html with this:
{% extends "admin/base.html" %}
{% load i18n %}
{% block title %}{{ title }} | {% trans "Administrative Area" %}{% endblock %}
{% block branding %}
<h1 id="site-name">{% trans "Administrative Area" %}</h1>
{% endblock %}
{% block nav-global %}{% endblock %}
{% block extrahead %}{{ block.super }}
<script src="{{media_url}}js/jquery.js" type="text/javascript"></script>
<script src="{{media_url}}fckeditor/fckeditor.js" type="text/javascript"></script>
<script src="{{media_url}}fckeditor/custom/vTextField.js" type="text/javascript"></script>
{% endblock %}
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.
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.)
JavaScript template for [GoogleAdmin](http://www.djangosnippets.org/snippets/1144/). Also requires the [google.html](http://www.djangosnippets.org/snippets/1145/) template. Install in `gis/admin` somewhere in your template path.
HTML template for [GoogleAdmin](http://www.djangosnippets.org/snippets/1144/). Also requires the [google.js](http://www.djangosnippets.org/snippets/1146/) template. Install in `gis/admin` somewhere in your template path.
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 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.
You're looking at the top-rated snippets currently on the site; if you'd like to contribute, sign up for an account and you'll be able to rate any snippet you see.