This is how you can access the user's request in the Form or FormSet definition, e.g. to define the choices of a ChoiceField dynamically.
Either you use it for a single Form or a whole FormSet, just pass the view's request into the Form or FormSet instantiation.
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'
])
OrderField for models from http://ianonpython.blogspot.com/2008/08/orderfield-for-django-models.html and updated to use a django aggregation function. This field sets a default value as an auto-increment of the maximum value of the field +1.
I had an issue with the django templating system, where by if I included several different files at the same level on one template.. and all the included templates extended the same base template. It would render the defined blocks for the first inclusion for all. i.e. everything in the parent that is being extended would be not updated for the subsequent inclusion.
So, if anyone else has this problem. I have a solution that I sorta wanted for other reasons anyway. It's called a decorator tag, you can include and extend a template at the same time - in-line, with local context scoping so it only affects that tag.
This is also a nice way to avoid creating .html files for simple extending purposes.
A very plugable way to get Stanislaus jquery dynamic formset working in the admin with adding just one template.
Add the following to templates/admin/APP/MODEL/change_form.html and also update the MODEL in the prefix setting.
Thanks Stanislaus
[http://elo80ka.wordpress.com/2009/10/10/jquery-plugin-django-dynamic-formset/](http://elo80ka.wordpress.com/2009/10/10/jquery-plugin-django-dynamic-formset/)
[http://go2.wordpress.com/?id=725X1342&site=elo80ka.wordpress.com&url=http%3A%2F%2Fcode.google.com%2Fp%2Fdjango-dynamic-formset%2F](http://go2.wordpress.com/?id=725X1342&site=elo80ka.wordpress.com&url=http%3A%2F%2Fcode.google.com%2Fp%2Fdjango-dynamic-formset%2F)
[http://www.djangosnippets.org/snippets/1389/](http://www.djangosnippets.org/snippets/1389/)
You have some tree-like structure in your models, for example:
`class MyModel(models.Model):
parent = models.ForeignKey('self', verbose_name=u'Parent', \
null=True, blank=True, related_name='children')
name = models.CharField(u'Раздел', max_lengtch=255)
position = PositiveSmallIntegerField(u'Позиция', default=0)
class Meta:
ordering = ('position',)`
To see it as a tree in admin's object list(you also can sort items, move to another parents by drag-n-drop; and rename them) add this to admin.py:
`class MyModelAdmin(admin.ModelAdmin):
ordering = ('position',)
list_display = ('pk','name','parent','position')
raw_id_fields =('parent',)
list_per_page = 900 #we sould have all objects on one page
list_editable = ('name','position','parent')
def parent_id(self,obj):
return obj.parent and obj.parent.id or '0'
class Meta:
model = MyModel
class Media:
js = [settings.MEDIA_URL + s for s in ('lib/jquery-1.3.2.min.js',
'lib/jquery.tree.min.js',
'lib/plugins/jquery.tree.contextmenu.js',
'lib/mymodel_admin.js',)]
css = {
'all':(settings.MEDIA_URL+'css/nestedsortablewidget.css',)
}`
mymodel_admin.js is the code listed here, if you have different title field(not "name"), change var title_column in javascript, list_display and list_editable.
jstree can be obtained here: [jstree](http://www.jstree.com/)
screenshot is in [my blog](http://tabed.org/blog/2010/01/06/jstree-in-django-admin/)
This snippet is helpful if you do a lot of editing on a single large admin form (for example, in a rich text field), and want to frequently save your progress. If you press control-S, or command-S on a Mac, the admin change form will save and reload, and the page will scroll back down to where you last were.
This snippet relies on jquery, [jquery.cookie](http://plugins.jquery.com/project/cookie), and the [shortcut.js](http://www.openjs.com/scripts/events/keyboard_shortcuts/) keyboard library (which doesn't use jquery, but seemed more robust than the jquery keyboard plugins I saw). It uses a temporary cookie to remember where the page was scrolled to, to avoid having to override the admin behavior.
Note: don't put this in templates/admin/change_form.html -- the circular import causes a Django crash.
*Edit: Had forgotten to include jquery.cookie, which I was already including elsewhere.*
A general AntiSpamModelForm using some tricks to prevent spam based on current [django.contrib.comments.forms](http://code.djangoproject.com/browser/django/trunk/django/contrib/comments/forms.py). It uses a timestamp, a security hash and a honeypot field. See [AntiSpamForm](http://www.djangosnippets.org/snippets/1925/) too.
This allows you to access the choices (and their respective values) you create as a dictionary. It works great within django and it allows you to reference the choices as a dictionary (CHOICES[CHOICE1]) instead of CHOICES[0][0]... it is a tuple... but I mean, come on... what if you change the order? If you need the tuple just call CHOICES.choices and it will return the standard tuple.
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
Ok... this is really a hack. But I love it. I hate setting up all of my test cases into suites, and making sure that I remember to add them each time I add a new python file... annoying! This allows me to have a tests package and then just add python files and packages to that test package (mirroring my app setup). Each of the files are then dynamically imported and every test case is automatically executed. If you don't want one to execute, add it to the ignore list. If you add 'views' to the ignore list, it will ignore all views, otherwise you would have to specify 'package.views' if it is in a package.
So... in short this is a bit ghetto, but it saves me a lot of time just setting up all my tests... now I can just write them! Hope it's useful to someone.
Greg
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