Snippet List
Subclass `Resource` to create a view that will dispatch based on the HTTP method of the request.
class View(Request):
def DELETE(self, request):
...
def GET(self, request):
...
def PUT(self, request):
...
Other snippets provided inspiration:
* [436](http://www.djangosnippets.org/snippets/436/)
* [437](http://www.djangosnippets.org/snippets/437/)
* [1071](http://www.djangosnippets.org/snippets/1071/)
* [1072](http://www.djangosnippets.org/snippets/1072/)
The code is also available on [GitHub](http://github.com/jpwatts/django-restviews/).
This is the approach I've taken to access instances of child models from their parent. Functionally it's very similar to snippets [1031](http://www.djangosnippets.org/snippets/1031/) and [1034](http://www.djangosnippets.org/snippets/1034/), but without the use of `django.contrib.contenttypes`.
Usage:
class Post(ParentModel):
title = models.CharField(max_length=50)
objects = models.Manager()
children = ChildManager()
def __unicode__(self):
return self.title
def get_parent_model(self):
return Post
class Article(Post):
text = models.TextField()
class Photo(Post):
image = models.ImageField(upload_to='photos/')
class Link(Post):
url = models.URLField()
In this case, the `Post.children` manager will return a queryset containing instances of the appropriate child model, rather than instances of `Post`.
>>> Post.objects.all()
[<Post: Django>, <Post: Make a Tumblelog>, <Post: Self Portrait>]
>>> Post.children.all()
[<Link: Django>, <Article: Make a Tumblelog>, <Photo: Self Portrait>]
- model
- manager
- queryset
- inheritance
**This is a model field for managing user-specified positions.**
Usage
=====
Add a `PositionField` to your model; that's just about it.
If you want to work with all instances of the model as a single collection, there's nothing else required. In order to create collections based on another field in the model (a `ForeignKey`, for example), set `unique_for_field` to the name of the field.
It's probably also a good idea to wrap the `save` method of your model in a transaction since it will trigger another query to reorder the other members of the collection.
Here's a simple example:
from django.db import models, transaction
from positions.fields import PositionField
class List(models.Model):
name = models.CharField(max_length=50)
class Item(models.Model):
list = models.ForeignKey(List, db_index=True)
name = models.CharField(max_length=50)
position = PositionField(unique_for_field='list')
# not required, but probably a good idea
save = transaction.commit_on_success(models.Model.save)
Indices
-------
In general, the value assigned to a `PositionField` will be handled like a list index, to include negative values. Setting the position to `-2` will cause the item to be moved to the second position from the end of the collection -- unless, of course, the collection has fewer than two elements.
Behavior varies from standard list indices when values greater than or less than the maximum or minimum positions are used. In those cases, the value is handled as being the same as the maximum or minimum position, respectively. `None` is also a special case that will cause an item to be moved to the last position in its collection.
Limitations
===========
* Unique constraints can't be applied to `PositionField` because they break the ability to update other items in a collection all at once. This one was a bit painful, because setting the constraint is probably the right thing to do from a database consistency perspective, but the overhead in additional queries was too much to bear.
* After a position has been updated, other members of the collection are updated using a single SQL `UPDATE` statement, this means the `save` method of the other instances won't be called.
More
===
More information, including an example app and tests, is available on [Google Code](http://code.google.com/p/django-positions/).
- lists
- models
- fields
- model
- field
- list
- sorting
- ordering
- collection
- collections
**This is an alternative to User.get_profile.**
Rather than having you call `User.get_profile` directly, this retrieves the profile instance for a `User` and attaches the fields from the profile to the `User` object when instantiated. The special methods for `DateField`, `FileField`, `ImageField` and fields with `choices` are also created.
Since the profile object still has to be retrieved from the database before its fields can be added to the `User`, the costs for using this might outweigh the rewards unless you are heavily using profiles.
To install, place it in a module on your `PYTHONPATH` and add it to `INSTALLED_APPS`.
- user
- profile
- auth
- userprofile
- profiles
**This is a newforms field for XFN relationships.**
It normalizes input by removing excess whitespace, converting to lowercase and removing duplicates.
This field also validates the relationship according to the [XFN profile](http://gmpg.org/xfn/11): `me` can only appear by itself and, at most, one value from each of the family, friendship and geographical categories is allowed.
The `XFN_*` constants would probably be imported from somewhere else in practice, but are included here for simplicity.
- newforms
- fields
- forms
- form
- field
- xfn
**This is a newforms field for OpenID 1 & 2.**
It normalizes and validates OpenID identifiers according to the [spec](http://openid.net/specs/openid-authentication-2_0.html#normalization):
* `xri://=joelwatts` to `=joelwatts`
* `joelwatts.com` to `http://joelwatts.com/`
* `www.joelwatts.com` to `http://joelwatts.com/`
An identifier that is well-formed, but not an OpenID (e.g. `example.com`), will cause a validation error.
Requires [Python OpenID Library](http://openidenabled.com/python-openid/) 2.x.x.
- newforms
- fields
- forms
- form
- field
- openid
- openid2
- inames
- identity
jpwatts has posted 6 snippets.