UnicodeFixer
This snippet is for resolve the Django-PyAMF unicode problems, through the django force_unicode function called recursively, with a tuple of different charsets.
- unicode
- utf-8
- object
- latin-1
- force_unicode
- pyamf
Snippet List
FormWizard inside view with proper context handling and site templating support, without having to use urls.py
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages) I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order. This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
- requestcontext
- views
- context
- form
- urls.py
- wizard
- formwizard
- views.py
Remember path decorator
Decorator that stores the `request.path` URL in a session variable to be used later, e.g. in a "Continue Shopping" link on a cart page. Wrap and view that you want to be able to link back to easily. When those views are called, it updates the session with the current `request.path` value. This can be pulled back out of the session whenever you need to provide a link back from whence the user came.
- session
- decorator
TrueNoneField
This custom model field is a variant of NullBooleanField, that stores only True and None (NULL) values. False is stored as NULL. It's usefull for special purposes like unique/unique_together. One small problem is here, that False is not lookuped as None. This snippets is a response to [1830](http://www.djangosnippets.org/snippets/1830/)
- null
- field
- custom-field
- none
PartialRequiredMultiValueField
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.
- form
- multivaluefield
Login as Any Site user
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)
- authentication
- user
- login
safe(r) monkeypatching scheme for django testing
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.
- testing
- monkeypatch
Build tags files for emacs and vim
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)
- tags
- emacs
- vim
Increase maximum number of changelist items for "Show all" link to appear
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.
- admin
- changelist
Past days template filter
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/)
- template
- filter
- date
Remove named field from fieldsets
This snipped removes a specific fields from the fieldsets. This is very useful to leave a field 'out' in the admin, likewise: def get_fieldsets(self, request, obj=None): fieldsets = super(BlaModelAdmin, self).get_fieldsets(request, obj) if not request.user.has_perm('change_blah'): remove_from_fieldsets(fieldsets, ('blah',))
- admin
- fieldset
- form
- field
- fieldsets
Template tag to clear cached template fragment
This is a custom template tag that clears the cache that was created with the **cache** tag. {% load clearcache %} {% clearcache [fragment_name] [var1] [var2] .. %} Create **app/templatetags** folder with **__init__.py** and copy code into **clearcache.py** file. polls/ templatetags/ __init__.py clearcache.py Based on django.templatetags.cache. See Django docs on [custom template tags](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/)
- template
- cache
- clear
- fragment
Variable._resolve_lookup monkeypatch
There are times when you want to hook into the Variable class of django.template to get extra debugging, or even to change its behavior. The code shown is working code that does just that. You can monkeypatch template variable resolution by calling patch_resolver(). I recommend using it for automated tests at first. My particular version of _resolve_lookup does two things--it provides some simple tracing, and it also simplifies variable resolution. In particular, I do not allow index lookups on lists, since we never use that feature in our codebase, and I do not silently catch so many exceptions as the original version, since we want to err on the side of failure for tests. (If you want to do monkeypatching in production, you obviously want to be confident in your tests and have good error catching.) As far as tracing is concerned, right now I am doing very basic "print" statements, but once you have these hooks in place, you can do more exotic things like warn when the same object is being dereferenced too many times, or even build up a graph of object interrelationships. (I leave that as an exercise to the reader.) If you want to see what the core _resolve_lookup method looks like, you can find it in django/templates/__init__.py in your installation, or also here (scroll down to line 701 or so): [source](http://code.djangoproject.com/browser/django/trunk/django/template/__init__.py)
- template
- variable
- resolve
UserProfileForm
We often need to use a Profile form and we want to be able to modify the first_name, last_name and sometimes the email address. Here is how I do it. In this case I want to check the email so I did a specific form for it. But it is quite easy to add it.
- user
- profile
- form
CSV Exporting of Model Data
This is a basic model view for exporting data from models. It is designed so that you can provide the GET variables used for searching/filtering within listdisplay pages in the admin, and the code will filter the same way. It allows the output of model data in various formats using serializers or templates.
- models
- export
- csv
- data
- reports