This very simple templatetag can take event objects from django-event-calendar and create the appropriate URLs to automatically allow users to add events from your website to Google calendar.
This is a fairly straightforward view to generate iCalendar (.ics) files, with a unique UUID, a proper filename, and the basic fields needed to export an event from a public calendar (using the django-events-calendar app). While it can certainly be extended and adapted, it works very well as-is.
This is a replacement for settings.py, which moves the actual settings files into a directory called "env" and establishes different versions for different settings of the environment variable DJANGO_ENV. At runtime, the specified development environment can be found and loaded into the local context of settings.py, which is then picked up by whatever routine manage.py is kicking off.
Put this into the __init.py__ file in the root of your project (the same directory level as urls.py and settings.py) and this installs _() as a global reference into the current running python VM, and now it’s as universally available as int(), map(), or str(). This is, of course, controversial. Modifying the python global namespace to add a function can be considered maintenance-hostile. But the gettext feature is so universal– at least to me– that __init__.py is where it belongs.
This code overrides the existing RegistrationForm in django-registration and adds a new validation step. In this step, the username (my example slug) is compared against all the existing URLs that the application currently resolves and, if it *does* successfully resolve, throws a validation exception. This indicates that the username chosen would be overriden (or, if you wrote your urls.py file badly, would override) an existing URL already recognized by your application. A much longer explanation can be found at [Dynamic names as first-level URL path objects in Django](http://www.elfsternberg.com/2009/06/26/dynamic-names-as-first-level-url-path-objects-in-django/).
For most applications, simplejson.dumps() is enough. But I’m especially fond of iterators, generators, functors (objects with a `__call__()` method) and closures, dense components that express one thought well: the structure of a tree, or the rows of a database, to be sent to the browser. The routine dumps() doesn’t understand any of those things, but with a simple addition, you can plug them into your code and be on your way without headache. Dumps() just calls JSONEncoder(), and JSONEncoder has a routine for extending its functionality. The routine is to override a method named default() (why “default?” I have no idea) and add the object types and signatures you want to send to the browser. Normally, this exists for you to provide custom “object to JSON” handlers for your objects, but there’s nothing custom about iterators, generators, functors and closures. They are native Python objects. This snippet provides the functionality needed by JSONEncoder to correctly dereference these useful Python objects and render their contents. (Originally posted [here](http://www.elfsternberg.com/2009/05/20/fixing-an-omission-from-djangos-simplejson-iterators-generators-functors-and-closures/) )
ElfSternberg has posted 6 snippets.