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))`
Passing datetimes from Python to a [YUI DataTable](http://developer.yahoo.com/yui/datatable/) via JSON served by [django-piston](http://bitbucket.org/jespern/django-piston/) turned out to be surprisingly rocky. This code actually works with ``YAHOO.lang.JSON.stringToDate`` (*not* ``YAHOO.util.DataSource.parseDate``) which cannot handle time zone specifiers other than "Z" or dates without timezones. The YUI [DataSource](http://developer.yahoo.com/yui/datasource/) which uses this looks something like this - note that simply setting ``format:"date"`` does not work as that uses ``YAHOO.util.DataSource.parseDate``, which uses``Date.parse`` to do the actual conversion, which will involve browser-specific formats and as of this writing only Chrome's native ``Date`` can reliably parse ISO 8601 dates. myDataSource.responseSchema = { resultsList: '…', fields: [ … { key: 'my_date_field', parser: YAHOO.lang.JSON.stringToDate }, ], … };
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.
This snippet is for resolve the Django-PyAMF unicode problems, through the django force_unicode function called recursively, with a tuple of different charsets.
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.
publish tldrelative rss news exampled web.montao.com.br/li
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/)
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/)
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)
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.
A simple replacement for Django's default GZipMiddleware which breaks when trying to serve files or pass any kind of iterators to the HttpResponse object. Simply replace GZipMiddleware with the provided middleware and set response.dontgzip = True when returning the response, and it will then be ignored by the middleware.
This is replace for django.contrib.redirects.RedirectFallbackMiddleware which redirects exact matches as well as startswith matches for the redirect.old_path I had a problem with my urls, because are dynamically generic, so I can't create one redirect entry on the database for each possible url. So I made django redirects to search any redirect with the exact match or any database entry being the head of my url, for example: I have django redirects which redirects /calendars/3434/ --> / . But when I have a 404 on /calendars/3434/c/2009/10/23/ now it redirects properly. So my redirects now acts as /calendars/3434/*
Django does not have a suitable model field can process time type in mysql, the DateTimeField built-in django can not process more than 24 hours. That's why the code born. **Simply usage** `from myapp.models import TimeAsTimeDeltaField, SECONDS_PER_MIN, SECONDS_PER_HOUR, SECONDS_PER_DAY class EstimatedTime: days = None hours = None minutes = None seconds = None class Case(models.Model): estimated_time = TimeAsTimeDeltaField(null=True, blank=True) def get_estimated_time(self): estimated_time = EstimatedTime() if self.estimated_time: total_seconds = self.estimated_time.seconds + (self.estimated_time.days * SECONDS_PER_DAY) days = total_seconds / SECONDS_PER_DAY hours = total_seconds / SECONDS_PER_HOUR - days * 24 minutes = total_seconds / SECONDS_PER_MIN - hours * 60 - days * 24 * 60 seconds = total_seconds % SECONDS_PER_MIN estimated_time.days = days estimated_time.hours = hours estimated_time.minutes = minutes estimated_time.seconds = seconds return estimated_time else: return estimated_time
Middleware to decorate views with user_passes_test in a centralized, url-matching manner. Makes it easy to apply permissions across large sections or all of a site.
I tried to think of a way to use generic views to show all my blog posts on one page organized chronologically with each post title under one month name and all the month names under one year name. Like so: ` 2009 October My last example blog entry Entry even before the last one First of October September Only one entry in Sept. 2008 December It is cold in December First posting of my blog ` I could not think of a way to do this using generic views, before I wrote a view and some template logic that does. The template logic is here: [http://www.djangosnippets.org/snippets/1765/](http://www.djangosnippets.org/snippets/1765/) Any suggestions for design patterns are greatly appreciated.