Having things like DATABASE_NAME in the admin interface is handy if you're working on development and deployment systems. Replace the template admin/base_site.html with the template code. The variables to be displayed in the admin need to be exported into the environment before running the server. The python code shown is an example of a wsgi handler, and the same format can be used in manage.py for the development server.
This is yet another partitioning filter, but I wanted to be able to distribute my objects across two columns, and have them read from left to right, top to bottom. So if n = 2 this would return every other object from a queryset. With gratitude to the author of snippet 6.
This is very simple Paginator function built over Django's Paginator. Just pass following:- 1. request object 2. object list - This is a list of object you want to paginate 3. per page - how many items you need per_page 4. paginator_range - Specify how many links you want on either side of current page link. Refer to Paginator reference [here](http://docs.djangoproject.com/en/dev/topics/pagination/)
simple routing views
Various list utilities.
I thought this code for insert automatically id in username field. This method should be used in save method. This code work on a dbms that support transactions ( example: mysql+innodb or postgresql ). Let me know what you think about this snippet and if you advice an alternative solution by commenting below. Thanks :)
This template tag is dead simple, if you have a file that is 45.3 kb, don't display it as 46,387 bits, display it as 45.3 kb!
CIDR ( http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing ) is a well-known IP range syntax. This CIDR_LIST class can be used to make ranges of IPs considered "internal" for Django's debugging and security purposes. (Django only ever needs to do "ip in INTERNAL_IPS" so __contains__ is sufficient for the purpose.) For example, to make localhost and the entire block of 10.0.0.* considered to be internal, use: INTERNAL_IPS = CIDR_LIST([ '127.0.0.1', '10.0.0.0/24' ])
Because the db caching doesn't support atomic operations, it was unsafe to store a list of 'keys' in a single key. So, rather than store the list, I just append each key with a specific tag, and then filter for it later. This means I don't need to worry too much about atomic usage with lists (i.e. queued requests). However - I still can think of many instances where I would need atomic usage, so I will probably implement this later on down the line. Hopefully, the atomic modifications will be accepted by the core devs. This also contains threaded cache cleaning, which means you no longer need to rely on requests to clean the cache (which would have potentially slowed the user query down), and will remove any cache entries past their expiry date every 3 minutes. Enjoy! Cal
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
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.)