automating twitter
Assume you have a model called Delegate and you want to tweet whenever a new Delegate registers, the code above will do this. You need to install python-twitter.
Assume you have a model called Delegate and you want to tweet whenever a new Delegate registers, the code above will do this. You need to install python-twitter.
This is a variation on dictsort that assumes objects with attributes, not dictionaries. Example usage: {% for book in author.book_set.all|sortby:'title' %}
This is an example of how you change a ChoiceField select widget into a hidden field if the right GET variable is passed. In this example code it would change the select widget into something like the following if something like "?d=3" was passed. `<p><label for="id_designation">Designation</label>Designation Option<input type="hidden" name="designation" value="3" id="id_designation" /></p>`
Browse through the installed models using the content types framework. There are two difference in behavior with respect to the default field: 1. if a model provides a translation for its name (e.g.: verbose_name and/or verbose_name_plural), it shows that rather than a raw model name 2. allow to filter the models shown through the use of `choice` parameter Example: `mbf = ModelBrowseField(choices=['User', 'Session'])`
Since r7806, the `User` field is unsorted which makes it harder to find specific users in the list if there is more than a few. This snippet is an `django.contrib.admin.ModelAdmin` subclass which searches through all of the fields on a form and automatically sorts fields which have a relation with `User`. It also filters on having `active=True`. Just import the `SortedActiveUserModelAdmin` class in your `admin.py` and subclass your `ModelAdmin` classes from it instead of `admin.ModelAdmin`.
If you use decorators to views, it will greatly improve readability and extensibility of your code. I'm using a couple of decorators like this to reduce complexity and redundancy in my view codes. `wraps` from Python 2.5's standard library make the attributes (name, docstring, and etc) of the decorated function same to those of `view_func` so that it could be easily recognized when you run `./manage.py show_urls` or debug.
An optparse action that let's you accept any parameters from the commandline. It stores them in another dictionary, inside the final options.
Suppose you want a decorator which takes multiple permissions. You can use permission_required which takes a single value.
The django_admin_log only logs changes, not simple requests. Sometimes it can be useful to log when a user of your admin interface is checking out important data, for instance if you are making a system with personal sensitive data, that needs to comply with government / company policies. This will log such hits to the django_admin_log by overriding the change_view method in ModelAdmin. So you must override this method in all classes you want to have logged.
Example of using django localeurl with sitemaps. Create sitemap instance for each combination of the sitemap section and language. In your sitemap class create method ` def location(self, obj): return chlocale(obj.get_absolute_url(), self.language) ` or inherit it from LocaleurlSitemap class.
When using the django admin as a means of moderating reviews on a site, the obvious choice was to use admin actions and do everything from a single screen. The I stumbled across was that after the actions were peformed, the app redirected to the change list without any filters. This meant that filtering on un-moderated reviews was lost as soon as a change was made. It turns out that the solution is pretty simple, you just put a redirect to request.get_full_path() at the end of the admin action. I think this should be the default behaviour, but the fix is simple nonetheless.
This is a small approach to have a middleware which automatically creates a ticket in an existing Trac environment. **Note:** you must have the [XML-RPC-Plugin](http://trac-hacks.org/wiki/XmlRpcPlugin) installed. Extend the attrs-dict to your needs. For example: in my case I have the SensitiveTicket-Plugin installed - automatically created tickets are marked as sensitive and are not visible to the public.
This is the manifest for being able to start django daemons via django-admin. A sample instance ('signet') is included.
DateTimeWidget using [JSCal2](http://www.dynarch.com/projects/calendar/) Duplicate of [this snippet](http://www.djangosnippets.org/snippets/391/), but for latest 1.5 version of DHTML Calendar. Also here is **fixed problem of previous widget** linked to *form.changed_data* and *EntryLog.message*. This is fixed by adding own, little modified *_has_changed()* method
Custom serialization, the poor try to make something like [django full serializers](http://code.google.com/p/wadofstuff/wiki/DjangoFullSerializers) Usage: you need two files, goodjson.py and goodpython.py, for example, in the root of application named "core". Then, add two lines into your settings.py: SERIALIZATION_MODULES = {'goodjson' : 'core.goodjson', 'goodpython': 'core.goodpython'} This thing does only serialization, not deserialization. You were warned.