Using the file plugin from django-cms can easily create a flowplayer with scrollable playlist as show in this example: http://flowplayer.org/demos/plugins/javascript/playlist/scrollable.htm
According to the KML Specification, Polygons must be oriented according to the Right-Hand Rule (Counter Clockwise orientation) for them to display correctly in Google Earth. Since not all Polygons are defined according to the Right-Hand Rule, you can use this code to orient them correctly when using GeoDjango. Thanks goes to jbronn of #geodjango on irc.freenode.net for this!
Defining a custom template tag consists of three parts: a compiling function, a rendering `Node` subclass and a tag registration with `register.tag()`. The latter can be used as a (function) decorator on the compiling function, simplifying things into two parts. A neat fact is that `register.tag()` can actually be used as a class decorator in Python 2.6+ to condense all steps into the `Node` subclass. The compiling function simply becomes the `__init__()`. Below are two variants of the 'current_time' tag example from the Django docs: the first passing an explicit tag name and the second using the class name instead.
This is my attempt at a convenience class for Django model choices which will use a [Small]IntegerField for storage. It's very similar to [jacobian's version](http://www.djangosnippets.org/snippets/1664/), but I wanted to be able to use simple attributes for access to the integer values. It's not technically dependent on Django, but it's probably not a datatype that would be useful for much else. Feel free to do so however if you have a use-case. >>> statuses = Choices( ... ('live', 'Live'), ... ('draft', 'Draft'), ... ('hidden', 'Not Live'), ... ) >>> statuses.live 0 >>> statuses.hidden 2 >>> statuses.get_choices() ((0, 'Live'), (1, 'Draft'), (2, 'Not Live')) This is then useful for use in a model field with the choices attribute. >>> from django.db import models >>> class Entry(models.Model): ... STATUSES = Choices( ... ('live', 'Live'), ... ('draft', 'Draft'), ... ('hidden', 'Not Live'), ... ) ... status = models.SmallIntegerField(choices=STATUSES.get_choices(), ... default=STATUSES.live) It's also useful later when you need to filter by your choices. >>> live_entries = Entry.objects.filter(status=Entries.STATUSES.live)
I am not sure what to say about the state of PyAWS, or its future, what with the multiple forks available and lack of recent updates. The best version I've found is [http://github.com/IanLewis/pyaws](this one), a spiffed-up version of 0.2.2 by Ian Lewis. I wrote this class on top of PyAWS so I could have more pythonic/django-y calling conventions, and to isolate the calls in case I have to swap libraries or versions down the road. You may want to familiarize yourself with PyAWS before using this. You'll definately need Amazon web service login credentials and keys -- they're available [here](http://aws.amazon.com/) for free. personally I use it with [these monkeypatching and decorator-decorators](http://www.djangosnippets.org/snippets/1888/) -- at the top of my personal version of the file containing this snippet I use the two (non-silly) examples from that snippet, to make the PyAWS internal Bag collection class work for me. EXAMPLE USE: # search Amazon's product database (returns a list of nested dicts) from amazon import aws books = aws.search(q='raymond carver') lenses = aws.search(q='leica summicron', idx='Photo') # get the data for a specific ASIN/ISBN/EAN/etc ID number what_we_talk_about_when_we_talk_about_love = aws.fetch(qid='0679723056', idtype='ASIN')
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.
Put this in your templates/admin/change_form.html template and you will be able to double click a manytomany in a multi select to be able to edit it.
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
3110 snippets posted so far.