This takes the "easier to ask forgiveness than permission" approach to making sure your model's slug is unique.
If the model's slug is empty, make a slug from the model's 'name' field.
We assume that it is a conflicting slug that is throwing the IntegrityError, in which case if the slug does not end with '-' followed by a number then append '-2'. If the slug does end with '-' followed by a number then capture that final number, increment it by one, save the new slug value and try savin g again.
Observation: depends on jQuery to works!
This widget works like other multiple select widgets, but it shows a drop down field for each choice user does, and aways let a blank choice at the end where the user can choose a new, etc.
Example using it:
class MyForm(forms.ModelForm):
categories = forms.Field(widget=DropDownMultiple)
def __init__(self, *args, **kwargs):
self.base_fields['categories'].widget.choices = Category.objects.values_list('id', 'name')
super(MyForm, self).__init__(*args, **kwargs)
This templatetag obsfucate mailto link and hide it while not happen onmouseover event.
Usage:
{% hide_email object.author object.author.email %}
Output:
<a href="mailto:[email protected]"
onmouseover="var a=String.fromCharCode(79+35,14+103,66+41,30+71,49+49,16+81);
var b=String.fromCharCode(14+50,9+105,61+56,81+26,92+9,2+96,20+77,13+33,75+24,32+79,31+78);
this.href=['mail','to:',a,b].join('');">rukeba</a>
Based on [Email Obsfucator](http://www.djangosnippets.org/snippets/536/) and [forums at Yandex.Market](http://market.yandex.ru/forums/).
Example at [my guitar blog](http://rukeba.com/ra/2008/01/15/oasis-wonderwall/)
Sometimes when sending email you want to specify a Return-Path different from the "From:" address on the email. The Return-Path is used for bounced email and is required for [VERP](http://en.wikipedia.org/wiki/VERP).
This class overrides SMTPConnection so that you can specify return_path.
New field type which allows prepopulate_from to work not only from javascript but in python too.
If the slugfield has unique=True creates a unique slug too.
This function generate an username based on the user's full name. First it tries to use the first name first letter plus the last name, second it tires the first name plus the last name first latter, and at last it tries to use the first name with a sequential number at the end.
The username generated are all lowercase and ASCII only characters.
Creates a filter for displaying calendars.
Passed value is a dict of dicts of arrays: that is, indexed by year, then by month. The list of month days is used to generate links in the format specified by the argument. If a particular day is *not* in the list, then no link will be generated and it will just display a number for that day.
**EXAMPLE**
`{{ calendar|calendar_table:"/schedules/calendar/[Y]-[m]-[d]/" }}`
This allows you to define a 'prefilter' function in your view modules which will be invoked before any view in that same. This provides an easy place to decorate the request or modify arguments.
For simplicity it doesn't allow configuration of the name of the prefilter function. I also skipped recursing into parent modules since that's somewhat edgecase.
A replacement test runner which outputs a coverage report after the tests. Simply change your ``TEST_RUNNER`` setting to point to ``run_tests_with_coverage`` and you're good to go.
Note that 'as-is' this snippet reports the coverage of all modules underneath the app, by walking the directory tree and loading all of the .py modules (this may be a naive approach).
If you change it to use `get_coverage_modules()` instead, it will only display the coverage of modules that have been imported by the test suite, using the Python `inspect` lib, which may be more reliable.
Uses [coverage.py](http://nedbatchelder.com/code/modules/coverage.html). Based on ideas from: [1](http://www.thoughtspark.org/node/6), [2](http://blogs.23.nu/c0re/stories/15428/) and [3](http://siddhi.blogspot.com/2007/04/code-coverage-for-your-django-code.html)
This javascript has the functionality of the 'Edit Object' bookmarklet as [described by James Bennett](http://www.b-list.org/weblog/2007/nov/07/bookmarklets/) but instead of putting it within a bookmarklet it creates a div on the page with a link to the main admin screen, an edit the object link, and logout link.
Just include the javascript on any page you want the links to show up on and make sure that the page is using the populate_xheaders function to provide the needed headers as [described here](http://www.b-list.org/weblog/2007/nov/07/bookmarklets/). The built in generic views provide the needed headers by default.
This middleware checks for xhtml mimetypes if the browser supports a "application/xhtml+xml" response. If not, it converts the response headers to "text/html".
To enable this middleware add it the the MIDDLEWARE_CLASSES setting and make sure it appears somewhere after GZipMiddleware, so that it's processed first.
This was born as a result of the fact that session data is shared across logins on a single browser. If you login as user1 and session data is stored, then login as user2 the same session data will be available to your application. Please see the ticket who's validity is at this point in question. Some feel that this is normal behavior.
http://code.djangoproject.com/ticket/6941
I use this code in conjunction with
http://code.google.com/p/django-registration/
Place this code in registration.__init__ and change registration.urls to have login and logout route to the new alternate versions alt_login, alt_logout.
I have only been using Python and Django for a couple months now so I hope that this implementation is not too terrible. It works for me. Enjoy.
This function is designed to make it easier to specify client-side query filtering options using JSON. Django has a great set of query operators as part of its database API. However, there's no way I know of to specify them in a way that's serializable, which means they can't be created on the client side or stored.
`build_query_filter_from_spec()` is a function that solves this problem by describing query filters using a vaguely LISP-like syntax. Query filters consist of lists with the filter operator name first, and arguments following. Complicated query filters can be composed by nesting descriptions. Read the doc string for more information.
To use this function in an AJAX application, construct a filter description in JavaScript on the client, serialize it to JSON, and send it over the wire using POST. On the server side, do something like:
> `from django.utils import simplejson`
> `filterString = request.POST.get('filter', '[]')`
> `filterSpec = simplejson.loads(filterString)`
> `q = build_query_filter_from_spec(filterSpec)`
> `result = Thing.objects.filter(q)`
You could also use this technique to serialize/marshall a query and store it in a database.
This template extends the change form for the flatpages inside the admin interface to use [Yahoo! User Interface Library](http://developer.yahoo.com/yui/)'s [Rich Text Editor](http://developer.yahoo.com/yui/editor/).
It should be named `change_form.html` and be placed in the `admin/flatpages/flatpage/` directory of the project templates.
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.