Modified version of [Profiling Middleware](http://www.djangosnippets.org/snippets/186/)
Prints profile results for method, additionally groups results by files and by modules (for django uses top level modules as groups). Works for Windows.
Usage: append ?prof or &prof= to any URL pointing to django application after adding ProfileMiddleware to middlewares in yours settings.py.
NOTICE: ProfileMiddleware uses hotshot profiler which is not thread safe.
This is a utility script that scans a models.py file and automatically outputs the corresponding newforms-admin source code - the code that goes into the admin.py file. The purpose is to simplify the migration to newforms-admin.
Here is what it outputs:
* an import line that lists only the needed classes from the model.
* inline editing classes - inheriting from either `admin.TabularInline` or `admin.StackedInline`
* admin options classes containing any original `Admin` class contents (`'fields'` is replaced by `'fieldsets'` and the value of `'classes'` is made into a tuple), plus the following fields whose values are determined automatically: `inlines`, `prepopulated_fields`, `filter_horizontal`, `filter_vertical` and `raw_id_fields`
* invokations of `admin.site.register` for the generated admin options classes.
Example usage of the script (this will generate the admin.py file for the models.py file in the satchmo.product module):
>./new-forms-gen.py satchmo.product > admin.py
This example shows how you can easily limit the objects in the admin by specifying which Manager the admin should use. I haven't seen this documented anywhere (perhaps I've missed it), but it's proven extremely useful to me.
The example here will limit objects to those that are attached to the current Site, but you can use any Manager you want (for example, a Manager that shows only published Articles).
Finally -- not that I'm suggesting this -- but you *could* combine this with the ThreadLocals trick to show only objects that have been created by that user.
This middleware replaces the behavior of the APPEND_SLASH setting in the CommonMiddleware. Please set `APPEND_SLASH = False` and `SMART_APPEND_SLASH = True` if you are going to use this middleware.
In your URL patterns, omit the trailing slash for URLs you want accessible without the slash. Include the slash for those URLs you wish to be automatically redirected from an URL with the slash missing.
If a URL pattern exists both with and without a slash, they are treated as two distinct URLs and no redirection is done.
Example
urlpatterns = patterns('some_site.some_app.views',
(r'^test/no_append$','test_no_append'),
(r'^test/append/$','test_append'),
(r'^test/distinct_url$', 'view_one'),
(r'^test/distinct_url/$', 'view_two'), )
Behavior of URLs against the above patterns with SMART_APPEND_SLASH enabled:
http://some_site/test/no_append → test_no_append()
http://some_site/test/no_append/ → 404
http://some_site/test/append → http://some_site/test/append/
http://some_site/test/append/ → test_append()
http://some_site/test/distinct_url → view_one()
http://some_site/test/distinct_url/ → view_two()
This module is also available [in our SVN repository](http://trac.ambitone.com/ambidjangolib/browser/trunk/middleware/common.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
Reviewing some statistic-middleware-classes I think you might need one wich is working correct and high-performant.
Please comment it and have fun with it!
I love newforms. But sometimes using ``{{ form }}`` within a template doesn't give you enough flexibility. The other option, manually defining the markup for each field, is tedious, boring and error-prone.
This is an example of how you can use a template filter to get the best of both worlds. Use it like this to render an entire form:
``{% for field in form %}``
{{ field|form_row }}
``{% endfor %}``
Or use it on a per-field basis:
``<fieldset>``
{{ form.first_name|form_row }}
{{ form.last_name|form_row }}
``</fieldset>``
This was inspired by [this memcache status snippet](http://www.djangosnippets.org/snippets/54/)
However, this version uses the quasi-internal cache._cache.get_status(), and it compiles a list of stats for each server that you specify in your CACHE_BACKEND setting.
**This is a newforms field for XFN relationships.**
It normalizes input by removing excess whitespace, converting to lowercase and removing duplicates.
This field also validates the relationship according to the [XFN profile](http://gmpg.org/xfn/11): `me` can only appear by itself and, at most, one value from each of the family, friendship and geographical categories is allowed.
The `XFN_*` constants would probably be imported from somewhere else in practice, but are included here for simplicity.
Requires the twitter module (easy_install python_twitter).
Your project settings file should define TWITTER_USERNAME.
Call the tag like:
`
{% get_twitter_status as tweet tweet_time tweet_url %}
<p><q cite="{{ tweet_url }}">{{ tweet }}</q> ({{ tweet_time }})</p>
`
**EDIT**: I've also included an alternative method as suggested in the comments. Called with:
`
{% get_twitter_status as tweet %}
<p><q cite="{{ tweet.url }}">{{ tweet.status }}</q> ({{ tweet.time }})</p>
`
[Original and further information available from here.](http://www.undefinedfire.com/articles/recursion-in-django-templates/)
**v1.1 Update (20/04/08):** Added the ability to recurse single elements as well as automatic skipping of empty elements.
Most of the tags are self explanatory, the only one that may cause confusion is the main `{% recurse %}` one. The format for this tag is `{% recurse [children] with [parent] as [child] %}` where “[children]” is the property that contains the children of the current element, “[parent]” is your starting element and “[child]” is the variable named used in the loop.
Example usage:
{% load recurse %}
... Headers and stuff ...
{% recurse category.category_set.all with categories as category %}
<ul>
{% loop %}
<li>
<h{{ level }}>{{ category.title }}</h{{ level }}>
{% child %}
</li>
{% endloop %}
</ul>
{% endrecurse %}
... The rest of the page ...
When given a model this utility method will export all data in that model to a CSV file. I use this method to place an "Export" button on a particular model's change list page in the Django administrator.