See the function **docstring** for usage. This template filter has a couple of drawbacks: * Uses **locale.setlocale** which, according to the [Python docs](http://docs.python.org/library/locale.html#locale.setlocale), is not thread safe. I don't know how this may affect Django applications. * Requires Python 2.5+. Updated 2011-03-16.
I was using flup to run django in fcgi mode and encountered the dreaded "Unhandled Exception" page quite frequently. So apart from all the precautions about handling this except, I wrote the above code snippet, which checks the import across your ENTIRE project. Ofcourse this can be used on any python project, but I have written it for my favorite framework django. It is now written as a Django command extension, an can be run as: **python manage.py imports_checker** This is a generic command, it does not check the settings.INSTALLED_APPS setting for cleaning. But can be improved to do the same. Public Clone Url: [git://gist.github.com/242451.git](git://gist.github.com/242451.git) Update: Now it supports checking imports, just only at the app level also usage: python manage.py imports_checker <appname>
If you are an admin of a django site and many times it feels to visualize or experience how a normal website user actually sees different pages of your website. So to get this done, we create a normal user (just for testing purposes) and check the same, which is good. But sometimes we need to actually login as the same person to resolve a issue or to trace a particular exception which only one user or a specific set of users are experiencing. Usage:login_using_email(request, "[email protected]") I have mentioned only the helper or core method which is responsible for the actual user "logging-in" simulation. Proper view permissions(remember I mentioned only admins should use this) can be wrapped around it. Any thoughts on improving it? Always invited.... Public Clone Url: [git://gist.github.com/242439.git](git://gist.github.com/242439.git)
publish tldrelative rss news exampled web.montao.com.br/li
This templatetag evaluates Python expressions including built-in functions, lambda functions etc... Use with caution.
The code shown implements a preprocessor for Django templates to support indentation-based syntax. The pre-markup language is called Showell Markup. It allows you to remove lots of close tags and random punctuation. It also has a syntax for cleaning up individual lines of HTML with a pipe syntax for clearly separating content from markup. You can read the docstrings to glean the interface. Here are examples: >> table >> tr >> td Right >> td Center >> td Left >> div class="spinnable" >> ul >> li id="item1" One >> li id="item2" Two %% extends 'base.html' %% load smartif %% block body %% for book in books {{ book }} %% if condition Display this %% elif condition Display that %% else %% include 'other.html' >> tr class="header_row" Original Author | th class="first_column" Commenters | th Title | th Action | th Last words | th By | th When | th >> ol class="boring_list" One | li Two | li Three | li {{ element4|join:',' }} | li Hello World! | b | span class="greeting" ; br Goodbye World! | i | span class="parting_words"; br ; hr >> p class="praise" Indentation-based syntax is so Pythonic! Archive LINK collection.archive referral.pk Home LINK home.home Friends LINK friendship.friends Create a card LINK referrals.create Recent changes LINK activity.recent_changes >> FORM referrals.create {{ form.as_p }} {{ referral.id } | HIDDEN referral
this solves a common problem where you want to specify html tag attributes for form fields in the template itself and not have to do it by writing a custom form class. eg. the size of the field, css classes, tabindex etc. usage: {% render_field form.comments "cols=40,rows=5,class=text,tabindex=2" %} where form.comments is a form field with a text area widget it will show data (if the form is bound or if there is initial data) and will display errors if the field has errors
Based on Snippet [766](http://www.djangosnippets.org/snippets/766/) & [799](http://www.djangosnippets.org/snippets/799/), edited for django 1.0 and higher.
A quick & dirty way of sorting the apps on the admin index page however you want. It requires you to override the default admin/index.html template. The instructions are in the docstring, they assume you insert the code above in a templatetag file called admin_app_order.py
In test code, it is sometimes useful to monkeypatch a Django method to have stubbed out behavior, so that you can simplify data setup. Even with decent data setup you might want to avoid execution of Django code that is not the target of your test. The code snippet shown here illustrates a technique to limit the scope of your monkeypatches. It uses the Python "with" statement, which was introduced in 2.5. [with statement](http://effbot.org/zone/python-with-statement.htm) The key aspect of the "with" machinery is that you can set up an __exit__ method that gets called even if the code inside the "with" raises an exception. This guarantees that your monkeypatch gets un-monkeyed before any other code gets called. I don't recommend monkeypatches in production, but if you HAVE to resort to a monkeypatch, I definitely advise using "with" to limit their scope. The examples on the left illustrate how to suppress versions of reverse() and timesince()--look at the import statements to see which ones I am talking about. Obviously, monkeypatching is not for the faint of the heart, as you need to be able to find the code to monkeypatch in Django source, and you need to be sure there aren't decorators at play.
Save this shell script to the root of your Django project as "tags.sh", make it executable with "chmod +x tags.sh", and run it from the project root with "./tags.sh", and you will have a "tags" file for vim and a "TAGS" file for emacs. Tags will be created for Python, JavaScript, and block names found in HTML templates. You may need to change "/usr/share/pyshared/django" to the location of your Django installation. Documentation on [Tags in emacs](http://www.gnu.org/software/emacs/manual/html_node/emacs/Tags.html) | [Tags in vim](http://vimdoc.sourceforge.net/htmldoc/tagsrch.html)
This a basic pagination example. It shows new 5 pnews items. We added a code to our template so we can view previous or next pages. It also show us how many pages we have.
It is often convenient to be able to specify form field defaults via GET parameters, such as /contact-us/?reason=Sales (where "reason" is the name of a form field for which we want a default value of "Sales"). This snippet shows how to set a form's initial field values from matching GET parameters while safely ignoring unexpected parameters.
By default, a "Show all" link will appear in the changelist pager only if fewer than 200 records are in the result. Since it is rare that there will be more than one page of records yet fewer than 200, the "Show all" link almost never shows up. Pasting this code somewhere in your app will allow you to increase the 200-record maximum. "Show all" is very handy when used in combination with batch actions and filters, and this change will enable it for most situations. Note that this allows a changelist with up to 10,000 results, which results in a lot of HTML that can tax slower browsers and older machines. For me, it has been worth the tradeoff, since my users have fast enough computers and need to be able to make batch changes efficiently.
This tag appends the current git revision as a GET parameter to a media files so the web server can set an expires header far in the future. Your project must be structured such that MEDIA_ROOT/../.git exists. Usage: `<link rel="stylesheet" type="text/css" href="{% media myapp/css/base.css %}">`