This is a replacement for Django's built-in ImageField. It uses the Google AppEngine image APIs in order to validate. Notes: 1. Validation of the field counts against your App Engine transformations quota. 2. This code assumes you're only using the in-memory file upload handler. None of the other stock handlers work well on App Engine; you should probably disable them.
Helper for identifing records in views similiar to rails dom_id helper.
Returns a list of date objects for a given number of past days, including today. Useful for summaries of recent history. Inspired by [Template range filter](http://www.djangosnippets.org/snippets/1357/)
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 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.
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)
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.
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
Based on Snippet [766](http://www.djangosnippets.org/snippets/766/) & [799](http://www.djangosnippets.org/snippets/799/), edited for django 1.0 and higher.
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
publish tldrelative rss news exampled web.montao.com.br/li
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)
Regarding to a quantity, use the singular or the plural in two distincts template variables.
Allows the whole widget to be required but still have optional fields in it. For instance we have a NameField, which takes a firstname and lastname and optionally a middlename. With this we can just have 1 widget.
This is a slight improvment of a previous snippet of mine: http://www.djangosnippets.org/snippets/1776/ It is an interactive shell script that greps and deletes sqlite tables USAGE: ./pdrop.sh myquery mydbfile