We needed to override the default QuerySet delete function to deal with a client problem that we were facing Yes This is monkey-patching, and probably bad practice but if anyone needs to conditionally override the cascading delete that django does at the application level from a queryset, this is how to do it
init env `env = Envoriment(extensions=('youproject.app.extensions.csrf_token'), loader=loader)` or see [http://www.djangosnippets.org/snippets/1844/] and in settings.py: `JINJA_EXTS=('jinja2.ext.i18n','youproject.app.extensions.csrf_token',)` use this extension in jinja2 template just like django template: `<form ...>{% csrf_token %}...</form>`
manything need to do with RequestContext, but it's too tedious. use `render_to_response("/my.html", {'key':value,},request)` instead of `render_to_response("/my.html", {'key':value,},new RequestContext(request)) ` and you can also use `render_to_response("/my.html", {'key':value,},new RequestContext(request))`
I tried a few snippets of integrated jinja2 in django, which provided ?.render_to_string and ?.render_to_response in the way of jinja2. **But those snippets could not use the generic view**, because of the generic views is use default django template. so i write this snippet which could use generic view, and use the basic django.shortcuts.render_to_string, django.shortcuts.render_to_string. #in yourproject/urls.py : #install default environment is very simple djangojinja2.install() #install environment of specified Environment class from jinja2.sandbox import SandboxedEnvironment djangojinja2.install(SandboxedEnvironment) #alternative you can install sepcified environment env=Environment(...) ... djangojinja2.install(env) #something could be set in settings.py TEMPLATE_DIRS = (path.join(path.dirname(__file__),"templates"),) JINJA_GLOBALS=['myapp.myutil.foo',] JINJA_FILTERS=['django.template.defaultfilters.date',] JINJA_TESTS=('foo.mytest',) JINJA_EXTS=['jinja2.ext.i18n'] #there is no change need for app.views from django.shortcuts import render_to_response def foo(request): return render_to_response('/myjinja2.html',{'request':request}) test in django development version of r12026 , jinja2 2.2.1, python 2.5
The Django Admin site provides a "raw ID" feature for foreign keys that reference large tables. In the form view, the label of the referenced object will appear after the input. This snippet will make that label into a hyperlink that takes you to the form view for that object. To use this snippet, copy base_site.html into your templates/admin directory (if you haven't already), and paste this code into that file somewhere after the 'extends "admin/base.html"' directive. If you are already using jQuery, you can remove the first script tag. If you are already extending "extrahead", just paste the script tag(s) into the block you have created. [Documentation for raw_id_fields](http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.raw_id_fields)
Perhaps you don't want to drop a table, but you also want to do something faster than Model.objects.all().delete() but without resorting to raw SQL. This function, clear_tables, will call the sql_flush operation on a list of tables.
simple_tag is nice, but it would be useful if it had a "as variable" clause at the end. This little bit of code factors out the reusable parts and makes a tag almost as simple as simple_tag. Now you can create tags like the following: {% some_function 1 2 as variable %} {% some_function db person %} To add a new function, just do: register.tag("new_function", make_tag(new_function)) (I think you have to take the quotes off a string.)
This snippet is for resolve the Django-PyAMF unicode problems, through the django force_unicode function called recursively, with a tuple of different charsets.
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)
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.
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/)
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
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.
Regarding to a quantity, use the singular or the plural in two distincts template variables.
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)
3110 snippets posted so far.