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.
After using Zope3/Grok for a little, I wondered how hard it would be to implement views as classes in Django, in a similar vain to how it's done in Grok. I came up with something rather simple but effective. It may be more appropriate if you use a template engine other than Django Templates, which allows you to call functions with arguments, but it's still useful none-the-less to encapsulate functions in a class.
You could, for example, extend View to be JinjaView, just replacing render_template().
A nice extension, I imagine, would be to automatically figure out the template name as well as the path prefix for it (since you probably want it to be found under packagename/templatename.html).
Complex of tags and filters for easy replacement of text with alternative font faces. For browsers, who doesn`t support it by themselves.
Templatetag code and documentation at [GitHub of django-headline](http://github.com/SkAZi/django-headline).
Yet another implementation of class based RESTful dispatch. This particular implementation features:
* You do not have to call __init__ from the derived classes.
* Avoids __metaclass__ which (in our environment) led to unexpected method override behavior.
* Method names match the google webapp API.
* One new instance per request to reduce errors in multi-threaded code.
Snippets of inspiration:
* [436](http://www.djangosnippets.org/snippets/436/)
* [437](http://www.djangosnippets.org/snippets/437/)
* [1071](http://www.djangosnippets.org/snippets/1071/)
* [1072](http://www.djangosnippets.org/snippets/1072/)
* [1226](http://www.djangosnippets.org/snippets/1226/)
A {% mailto %}{% endmailto %} template tag that requires an e-mail destination and optionally accepts subject, cc and bcc. It will then wrap whatever is within the tag in an `<a href="mailto:..."> </a>` HTML tag.
See the docstring in the code for the {% mailto %} usage and some examples.
You will need to load this template tag to your template. You can find detailed instructions [here](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#code-layout). But in a nutshell:
1. Create a templatetags package (meaning a directory with a __init__.py file in it) on the same level as your application's model.py
2. Put the code for this tag in a module (example: extra_tags.py)
3. On your template use {% load extra_tags %} -- note: the app where the templatetags package was created needs to be in INSTALLED_APPS
4. Use {% mailto user.email 'You subject here for {{user.get_full_name}}' %}blah{% endmailto %}
This is my first django template tag. I am also NOT tremendously experienced with Python. Criticism and corrections are more than welcome.
AdminImageWidget is a ImageField Widget for admin that shows a thumbnail.
Usage example on a form:
class IconForm(forms.ModelForm):
icon = forms.ImageField(label='icon', widget=AdminImageWidget)
Based *very heavily* on the middleware in [this snippet](http://www.djangosnippets.org/snippets/727/). As with that one, append '?prof' to the URL to see profiling output instead of page output. The big change is that you can also pass an argument to control sorting.
For example, you can append '?prof=cumulative' to sort the results by the cumulative time consumed. See the [documentation on the Stats class](http://docs.python.org/library/profile.html#pstats.Stats.sort_stats) for all the options.
This middleware implements a "soft timeout". This means the admin is sent an email whenever a page time exceeds a certian value. It is intended to run on production servers to inform the admin of any pages which are performing slowly.
A number of people have kindly posted snippets on how to use pdb/ipdb with django. However, this only works when running the django development server.
I thought it would be nice to have a trace() command that would turn into a no-op when the development server is not running, so you wouldn't have to worry about leaving trace() commands in your code if you want to quickly test with mod_wsgi or mod_python.
The code above attempts (on Posix-like systems) to determine if the development server is running (by quickly checking if "manage.py runserver" is in the process list), and sets a DJANGO_SERVER setting appropriately. Then when you import the trace() method, it is defined as set_trace() if DJANGO_SERVER is True, or a no-op if DJANGO_SERVER is False.
When you hit the trace() in pdb/ipdb, enter "u" to go up to the calling trace() statement.
This tag builds on top of the [ifusergroup/else tag](http://www.djangosnippets.org/snippets/390/), fixes a small bug and introduces support for else blocks. This adds a way to provide multiple groups via group1|group2|group3
Sometimes you just need to count things (or create unique-for-your-application IDs). This model class allows you to run as many persistent counters as you like. Basic usage looks like this:
>>> Counter.next()
0
>>> Counter.next()
1L
>>> Counter.next()
2L
That uses the "default" counter. If you want to create and use a different counter, pass its name as a string as the parameter to the method:
>>> Counter.next('hello')
0
>>> Counter.next('hey')
0
>>> Counter.next('hello')
1L
>>> Counter.next('hey')
1L
>>> Counter.next('hey')
2L
You can also get the value as hex (if you want slightly shorter IDs, for use in URLs for example):
>>> Counter.next_hex('some-counter-that-is-quite-high')
40e
The code posted here adds "elif" functionality to the [smart if snippet 1350](http://www.djangosnippets.org/snippets/1350/).
To use the snippet first follow the instructions for installing smart_if, then swap in the method shown on the left for the original smart_if method. You'll need to keep all the supporting classes from the original implementation, of course.
You can use it like this:
{% if 0 %}
{% if 1 %}
Hello Venus
{% else %}
unexpected
{% endif %}
{% elif 0 %}
Hello Earth
{% elif 0 %}
Foo
{% else %}
Hello Mars
{% endif %}
The code is compatible with original smart_if classes as of June 2009, and the use of "__contains__" in the Enders class relies on the current implementation of Parser.parse, which says "if token.contents in parse_until:" in the one place it uses the parse_until parameter, which seems like stable code to me.
The code works by recursively creating SmartIfNodes for the elif clauses.
This snippet is a variation on snippet 1550 that works with the Eclipse pydev plugin.
This allows you to set up a breakpoint anywhere in your template code, by simply writing {% pydev_debug %}. Be sure to launch pydev in debugger mode first.
Once you're in the debugger, you can explore the stack and quickly find which context variables are set. This can be especially useful inside for loops, etc., where you want to see how the templating code is mucking with the context. This can also be useful when your templates are ultimately rendered by code that might not understand very well, such as generics.