Automatically slugify slug fields in your models

*I suppose I'm kind of stubborn, but I prefer to use underscores to replace spaces and other characters. Of course, that shouldn't hold you back from using the build-in slugify filter :)* ** Forcing the slug to use ASCII equivalents: ** Transforming titles like "Äës" to slugs like "aes" was kind of a trial and error job. It now works for me. I hope `_string_to_slug(s):` proves a rather stable solution. Yet the worst-case scenario is that such characters are lost, I guess that is acceptable. Other ways of dealing with this problem can be found at [Latin1 to ASCII at Activestate](http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/251871) or in the comments below. **How to use:** The slug fields in your model must have prepopulate_from set, the fields specified in it are used to build the slug. To prevent duplicates, a number is added to the slug if the slug already exists for the current field in another, previous, object. I guess there should be a cleaner way to distinguish between creating a new db entry or updating an existing one, sadly, the db back-end is kind of a black-box to me. At least this works ;) I choose not to alter the slug on an update to keep urls more bookmarkable. You could even extend this further by only updating the slug field if it hasn't been assigned a value.

• slug
• dispatcher
• events

Tue 15 Feb 2011 Read More

Django google maps v3 snipplet

Almost copied from snipplet http://djangosnippets.org/snippets/752/, but I used Google Maps API v3

• google
• maps
• widget
• v3

Wed 05 Sep 2012 Read More

SortableModel - abstract model class for sortable records

If you have a model that has an "ordering" column, and you want to be able to re-position records (eg, order items by priority), this base class should make it fairly easy. To use it, you extend your model using this abstract class, then hook up the pre_save event to the pre_save event of the base class, and you're good to go. Whenever you save an item, it ensures that it has a valid "order" number. The meat of this class is the "move()" method. Just call instance.move(number) where instance is your model instance, and this class will do all the logic necessary to shift around the order numbers for you.

• sort
• order
• sortable
• orderable
• sorted
• ordered

Sun 21 Oct 2012 Read More

Pagination/Filtering Alphabetically

This allows you to create an alphabetical filter for a list of objects; e.g. `Browse by title: A-G H-N O-Z`. See [this entry](http://developer.yahoo.com/ypatterns/pattern.php?pattern=alphafilterlinks) in Yahoo's design pattern library for more info. NamePaginator works like Django's Paginator. You pass in a list of objects and how many you want per letter range ("page"). Then, it will dynamically generate the "pages" so that there are approximately `per_page` objects per page. By dynamically generating the letter ranges, you avoid having too many objects in some letter ranges and too few in some. If your list is heavy on one end of the letter range, there will be more pages for that range. It splits the pages on letter boundaries, so not all the pages will have exactly `per_page` objects. However, it will decide to overflow or underflow depending on which is closer to `per_page`. **NamePaginator Arguments**: `object_list`: A list, dictionary, QuerySet, or something similar. `on`: If you specified a QuerySet, this is the field it will paginate on. In the example below, we're paginating a list of Contact objects, but the `Contact.email` string is what will be used in filtering. `per_page`: How many items you want per page. **Examples:** >>> paginator = NamePaginator(Contacts.objects.all(), \ ... on="email", per_page=10) >>> paginator.num_pages 4 >>> paginator.pages [A, B-R, S-T, U-Z] >>> paginator.count 36 >>> page = paginator.page(2) >>> page 'B-R' >>> page.start_letter 'B' >>> page.end_letter 'R' >>> page.number 2 >>> page.count 8 In your view, you have something like: contact_list = Contacts.objects.all() paginator = NamePaginator(contact_list, \ on="first_name", per_page=25) try: page = int(request.GET.get('page', '1')) except ValueError: page = 1 try: page = paginator.page(page) except (InvalidPage): page = paginator.page(paginator.num_pages) return render_to_response('list.html', {"page": page}) In your template, have something like: {% for object in page.object_list %} ... {% endfor %} <div class="pagination"> Browse by title: {% for p in page.paginator.pages %} {% if p == page %} <span class="selected">{{ page }}</span> {% else %} <a href="?page={{ page.number }}"> {{ page }} </a> {% endif %} {% endfor %} </div> It currently only supports paginating on alphabets (not alphanumeric) and will throw an exception if any of the strings it is paginating on are blank. You can fix either of those shortcomings pretty easily, though.

• pagination
• paginator
• filtering

Tue 25 Jun 2013 Read More

MarkupField

This is a field that allows multiple markup types but also stores the pre-rendered result in the database which offers an advantage over calling one of the render methods each time. Example usage looks like: class BlogPost(models.Model): ... post = MarkupField() the various extra fields can then be accessed as follows: BlogPost.objects.get(pk=1).post # raw content BlogPost.objects.get(pk=1).post_markup_type # markup type (plain text, html, markdown, rest, textile) BlogPost.objects.get(pk=1).post_rendered # content of post rendered to html BlogPost.objects.get(pk=1).post_as_html # property that access post_rendered but marked safe for easy use in templates After writing my initial version of this I was pointed at the similar http://www.djangosnippets.org/snippets/1169/ I find mine a bit more useful as it includes ReST and includes a mark_safe call to allow showing the rendered HTML directly. I have however borrowed the nice idea of dynamically building MARKUP_TYPES from #1169. Also available via http://gist.github.com/67724.

• fields
• rest
• markup
• markdown
• textile
• restructuredtext

Wed 26 Feb 2014 Read More

Command to make fixtures.

"Make fixture" command. Highly useful for making test fixtures. Use it to pick only few items from your data to serialize, restricted by primary keys. By default command also serializes foreign keys and m2m relations. You can turn off related items serialization with `--skip-related` option. How to use: python manage.py makefixture will display what models are installed python manage.py makefixture User[:3] or python manage.py makefixture auth.User[:3] or python manage.py makefixture django.contrib.auth.User[:3] will serialize users with ids 1 and 2, with assigned groups, permissions and content types. python manage.py makefixture YourModel[3] YourModel[6:10] will serialize YourModel with key 3 and keys 6 to 9 inclusively. Of course, you can serialize whole tables, and also different tables at once, and use options of dumpdata: python manage.py makefixture --format=xml --indent=4 YourModel[3] AnotherModel auth.User[:5] auth.Group

• serialize
• admin
• model
• fixtures
• tests
• test
• management
• commands
• fixture
• command
• make

Fri 14 Jan 2011 Read More

backupdb command

`backupdb` command allows to make a database backup automatically. It's supposed to do this just before a `syncdb`, `reset` or `flush` command in a server deployment. A usual upgrade task in production server could be: ./manage.py backupdb ./manage.py reset myapp ./manage.py syncdb Put this code in your project's `management/commands/backupdb.py` file.

• management
• command
• django-admin

Wed 25 Apr 2012 Read More

DebugFooter middleware with Pygments sql syntax highlighting

Based on Snippet [766](http://www.djangosnippets.org/snippets/766/) but added syntax highlighting of the sql output via [pygments](http://pygments.org/). The sql output will also be wrapped at 120 characters by default (can be configured by changing WRAP). It degrades nicely if pygments is not installed. This will add quite some cpu-cycles just for printing debug messages so use with care. Following is the rest of the original description by [simon](http://www.djangosnippets.org/users/simon/) (shamelessly copied): Adds a hidden footer to the bottom of every text/html page containing a list of SQL queries executed and templates that were loaded (including their full filesystem path to help debug complex template loading scenarios). To use, drop into a file called 'debug_middleware.py' on your Python path and add 'debug_middleware.DebugFooter' to your MIDDLEWARE_CLASSES setting. Edit: Added the ability to set the height of the debug-box

• sql
• middleware
• debugging

Sun 11 Jul 2010 Read More

MintCache (simple version)

This is intended as an alternative to http://www.djangosnippets.org/snippets/155/ Put this in your own cache.py and import it instead of django.core.cache and use it the same way. We left out the "add" function but it shouldn't be too hard to make if you want it. From the above post: "The purpose of this caching scheme is to avoid the dog-pile effect. Dog-piling is what normally happens when your data for the cache takes more time to generate than your server is answering requests per second. In other words if your data takes 5 seconds to generate and you are serving 10 requests per second, then when the data expires the normal cache schemes will spawn 50 attempts a regenerating the data before the first request completes. The increased load from the 49 redundant processes may further increase the time it takes to generate the data. If this happens then you are well on your way into a death spiral MintCache works to prevent this scenario by using memcached to to keep track of not just an expiration date, but also a stale date The first client to request data past the stale date is asked to refresh the data, while subsequent requests are given the stale but not-yet-expired data as if it were fresh, with the undertanding that it will get refreshed in a 'reasonable' amount of time by that initial request."

• cache
• memcached
• caching
• mintcache

Sat 07 Jul 2012 Read More

Ajax required decorator

Checks if the request is an AJAX request, if not it returns an HttpResponseNotFound. It looks for the XMLHttpRequest value in the HTTP_X_REQUESTED_WITH header. Major javascript frameworks (jQuery, etc.) send this header in every AJAX request.

• ajax
• decorator
• decorators
• xmlhttprequest
• ajax-required

Wed 01 Jul 2015 Read More

DropDownMultiple widget

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)

• newforms
• multiple
• forms
• jquery
• select
• widget

Tue 24 Apr 2018 Read More

Dynamic Django form

This is a little snippet that you can use to make your Django newforms dynamic at runtime. You can define an arbitrary number of fields of the form without loosing newforms capibilites. You can render the form dynamically be "misusing" the "help_text" attribute of the form fields (Every form field allows the definition of this attribute). This way you can search for changes in the help_text of every field and render the form accordingly. The form itself is dynamically defined in the view. The form state can be saved in a Django Session Variable (specifically for Linux users with a process-based Apache Server), so that you can rebuild and verify a submitted form.

• newforms
• dynamic-form
• runtime
• custom-forms

Fri 17 Oct 2014 Read More

Django and Twill

Django's test client is very limited when it comes to testing complex interactions e.g. forms with hidden or persisted values etc. Twill excels in this area, and thankfully it is very easy to integrate it. * Use `twill_setup` in your `TestCaseSubClass.setUp()` method * Use `twill_teardown` in `TestCaseSubClass.tearDown()` method * In a test, use something like `make_twill_url()` to generate URLs that will work for twill. * Use `twill.commands.go()` etc. to control twill, or use `twill.execute_string()` or `twill.execute_script()`. * Add `twill.set_output(StringIO())` to suppress twill output * If you want to write half the test, then use twill interactively to write the rest as a twill script, use the example in `unfinished_test()` Twill will raise exceptions if commands fail. This means you will get 'E' for error, rather than 'F' for fail in the test output. If necessary, it wouldn't be hard to wrap the twill commands to flag failure with TestCase.assert_ There are, of course, more advanced ways of using these functions (e.g. a mixin that does the setup/teardown for you), but the basic functions needed are here. See also: * [Twill](http://twill.idyll.org/) * [Twill Python API](http://twill.idyll.org/python-api.html)

• testing
• tests
• twill

Mon 24 Dec 2012 Read More

Different approach to local settings.py

I like to keep all local settings files in my versioning repository. The way I differentiate between them is by querying the hostname of the local machine. I've got a host_settings folder with local settings files. Notice that the local settings file names go by a convention where '.' is replaced with underscores. Example: host_settings/local_machine_tld.py

• settings
• development
• deployment

Sun 11 Jul 2010 Read More

AjaxCheckMiddleware

Simply adds an attribute `is_ajax` to a request object, indicating if the request was made via Ajax. Allows you to reuse a lot of POST processing view code to which you'd like to progressively add Ajax: `if request.is_ajax: return JsonResponse(some_json)` `else: return render_to_response('some_template.html')`

• middleware
• ajax
• request

Sun 11 Jul 2010 Read More