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.
This class runs a django test server in another thread. This is very useful for e.g. selenium integration. Simple to integrate into django test framework.
Usage:
server = TestServerThread("127.0.0.1", "8081")
server.start()
# Run tests e.g.
req = urllib.urlopen("http://127.0.0.1:8081")
contents = req.read()
server.stop()
ps. I don't actually double space my code :). Not sure whats up with that!
I'm using Django's FlatPages, but I want to be able to restrict admin access to Users based on a FlatPage url. For example, User John Doe should be able to edit any FlatPage objects whose URL begins with `/johndoe/` (such as `/johndoe/about/` or `/johndoe/projects/whatever/`).
For this to work, John Doe would already need the appropriate admin permissions for FlatPage (such as can_add and can_change).
I have set this up as a separate *flatpage_addons* app. It consists of the **Permission** model, which maps a starting URL to one or more django Users. It consists of the minimal necessary admin code so Permissions can be created using the admin.
The bulk of this code consists of the *ifhasflatpagepermission* template tag as well as the *flatpage_result_list* inclusion tag. The former works much like django's existing *if*, *else*, *endif* tags while the latter is modified from the django admin's *result_list* inclusion tag.
This may not be the most elegant solution to my problem, but so far it works for me. Any comments or suggestions are welcome!
Inserts the output of a view, using fully qualified view name (and then some
args), a or local Django URL.
{% view view_or_url arg[ arg2] k=v [k2=v2...] %}
This might be helpful if you are trying to do 'on-server' AJAX of page
panels. Most browsers can call back to the server to get panels of content
asynchonously, whilst others (such as mobiles that don't support AJAX very
well) can have a template that embeds the output of the URL synchronously
into the main page. Yay! Go the mobile web!
Follow standard templatetag instructions for installing.
**IMPORTANT**: the calling template must receive a context variable called
'request' containing the original HttpRequest. This means you should be OK
with permissions and other session state.
**ALSO NOTE**: that middleware is not invoked on this 'inner' view.
Example usage...
Using a view name (or something that evaluates to a view name):
{% view "mymodule.views.inner" "value" %}
{% view "mymodule.views.inner" keyword="value" %}
{% view "mymodule.views.inner" arg_expr %}
{% view "mymodule.views.inner" keyword=arg_expr %}
{% view view_expr "value" %}
{% view view_expr keyword="value" %}
{% view view_expr arg_expr %}
{% view view_expr keyword=arg_expr %}
Using a URL (or something that evaluates to a URL):
{% view "/inner" %}
{% view url_expr %}
(Note that every argument will be evaluated against context except for the
names of any keyword arguments. If you're warped enough to need evaluated
keyword names, then you're probably smart enough to add this yourself!)