Simple Python snippet to detect if any word in a list of words is inside your string. Use for profanity checking (my use case), auto tag detection, scoring, etc. This will return an empty list if the word is not in the list. Assumes everything in words_to_find is lower case. Can probably be done cleaner with regular expressions but this method is extremely readable for those that prefer none regex solutions.
signal handler for checking unique_together manually. Also available via django-tools: http://code.google.com/p/django-tools/
This is the manifest for being able to start django daemons via django-admin. A sample instance ('signet') is included.
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.
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.
Suppose you want a decorator which takes multiple permissions. You can use permission_required which takes a single value.
An optparse action that let's you accept any parameters from the commandline. It stores them in another dictionary, inside the final options.
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.
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`.
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>`
This is a variation on dictsort that assumes objects with attributes, not dictionaries. Example usage: {% for book in author.book_set.all|sortby:'title' %}
Add RequestMiddleware to your MIDDLEWARE_CLASSES settings Then, when you need request in special cases, call get_request(), which returns the request object. This has to be used in very special cases.
A better way of dealing w/profanity - disemvowel it! From [Wikipedia](http://en.wikipedia.org/wiki/Disemvoweling), "disemvoweling is a technique used to censor unwanted postings such as spam, internet trolling, rudeness or criticism and yet maintain some transparency, both of the act and the underlying word." Credit: Boing Boing Example: This original sentence: In the fields of Internet discussion and forum moderation, disemvoweling (also spelled disemvowelling) is the removal of vowels from text. would be disemvowelled to look like this: n th flds f ntrnt dscssn nd frm mdrtn, dsmvwlng (ls splld dsmvwllng) s th rmvl f vwls frm txt. Usage: body_input = form.cleaned_data["body"] body_input = disemvowel_profanity(body_input)
This set of handlers allow one to isolate requests based on the method posted. Normally, in a view, we would do checks for request.method value and update the resource accordingly. This makes the view code pretty messy. So one way to avoid these check each time is to have a handler method (resource_handler above), that checks for the method parameter and dispatches to the handler withe the prefix <method>_handler_<suffix>. This also has the advantage of grouping related actions in a particular class. At the same time a new instance of the request handler is not created on each request (as with the google appengine handler?). Yet another advantage is by making the handler methods as class methods, the handler classes can be inherited to add further functionality to a resource "group. The disadvantage however is the inability to restrict access to a handler method to only particular methods. Eg above the "r'obja/(?P<id>[^\/]+)/delete/" would map to the delete_handler_objects if themethod was "delete" and post_handler_objects if the method was "post". However this can be worked with a different suffix passed to the handler_params method. Infact setting the suffix to "objects_delete" would result in a "delete_handler_objects_delete" handler on delete method and a Http404 on all others. Another inconvinience is the inability to detect a view handler by simply inspecting the url patterns. However, this information is carried within the handler_suffix and handler_class parameters which may infact provide greater insight into the semantics around the view handlers. Needless to say, this easily extends rest based accesses. Would greatly appreciate feedback and improvements.
from url_helper import execute, url_ import views urlpatterns += patterns('', url(r'^(?P<urls>.*)', execute, {'views': views}), ) url_(r’/space/:username/:tag/’, views.url_), equal url(r’^space/(?P[^/]+)/(?P[^/]+)/$’,