LoginRequiredMixin
Provides a mixin view class that requires logged-in user.
- view
- mixin
- class
- login-required
Provides a mixin view class that requires logged-in user.
More a proof of concept than anything, this mixin addresses a perceived "shortcoming" of django forms: the inability to interact with the current request, and specifically the "current user". Usage: class SomeForm(forms.Form, RequestFetchingMixin): # fields... def __init__(self, *args, **kwargs): if self.request: # interact with self.request? super(SomeForm, self).__init__(*args, **kwargs) if self.request: # more interaction def clean(self): if self.request: # blah blah self.request.user blah Notes: * This reaches "into the past" to pull an existing HttpRequest object, regardless of what name it was bound to, into "the present". * If multiple requests are found (what on earth are you doing??), the one bound to "request" (or the first one found, if that's not available) will be used. * By default it goes up to 5 frames back before giving up, but that can obviously be changed if you think you need it. * This won't work everywhere. self.request is guaranteed to be present, but may be None. * Just because you have a self.request doesn't mean self.request.user will be a valid user. This is subject to all the rules that a regular view's request is subject to (because it *is* a regular view's request!) * This isn't magic; it's just python.
Enables convenient adding of fields, methods and properties to Django models. Instead of: User.add_to_class('foo', models.CharField(...) User.add_to_class('bar', models.IntegerField(...) you can write: class UserMixin(ModelMixin): model = User foo = models.CharField(...) bar = models.IntegerField(...)
Template designers often require access to individual form fields or sets of form fields to control complex form layouts. While this is possible via looping through form fields in the template it can lead to ugly logic inside templates as well as losing the ability to use the as_* form rendering methods. This class when mixed into a form class provides hooks for template designers to access individual fields or sets of fields based on various criteria such as field name prefix or fields appearing before or after certain fields in the form, while still being able to use the as_* form rendering methods against these fields.
Example mixin for creating and removing thumbnails on a model. Also adds some methods for accessing an url for an image size. It might be a better idea to use a custom image field instead of this approach. Idea for getting the image url for different sizes from http://code.google.com/p/django-photologue Example usage <pre> >>> p.get_small_image_url() u'http://127.0.0.1:8000/site_media/photos/small_someimage.jpg' </pre>
There are several nice ModelAdmin subclasses that provide useful functionality (such as django-batchadmin, django-reversion, and others), but unfortunately a ModelAdmin can really only subclass one at a time, making them mutually exclusive. This snippet aims to make mixing these classes in as easy as possible -- you can inherit your model admin from it, add a tuple of mixins, and it will dynamically change the inheritance tree to match. This isn't guaranteed to work with all ModelAdmins, but so long as the mixins play nice with django modeladmin they *should* work.
Add's updated and created fields to a model if mixed in. Example that uses the name as the representation: class Company(models.Model, UnicodeReprMixIn): """ A representation of a comic book company. """ name = models.CharField(max_length=255) slug = models.SlugField() logo = models.ImageField(upload_to=os.path.join('upload', 'company_logos')) url = models.URLField(verify_exists=True) _unicode = "name"
Add this as a superclass of any Django model to allow making copies of instances of that model: class Entry(models.Model, CloneableMixin): [...] e = Entry.objects.get(...) e_clone = e.clone() e_clone.title = 'Cloned Entry' e.save() The new object is saved during the clone process and ManyToMany relations are copied as well.
Every now and then you need to have items in your database which have a specific order. As SQL does not save rows in any order, you need to take care about this for yourself. No - actually, you don't need to anymore. You can just use this file - it is designed as kind-of plug-in for the Django ORM. Usage is (due to use of meta-classes) quite simple. It is recommended to save this snippet into a separate file called `positional.py`. To use it, you only have to import `PositionalSortMixIn` from the `positional` module and inherit from it in your own, custom model (but *before* you inherit from `models.Model`, the order counts). Usage example: Add this to your `models.py` from positional import PositionalSortMixIn class MyModel(PositionalSortMixIn, models.Model): name = models.CharField(maxlength=200, unique=True) Now you need to create the database tables: `PositionalSortMixIn` will automatically add a `postition` field to your model. In your views you can use it simply with `MyModel.objects.all().order_by('position')` and you get the objects sorted by their position. Of course you can move the objects down and up, by using `move_up()`, `move_down()` etc. In case you feel you have seen this code somewhere - right, this snippet is a modified version of [snippet #245](/snippets/245/) which I made earlier. It is basically the same code but uses another approach to display the data in an ordered way. Instead of overriding the `Manager` it adds the `position` field to `Meta.ordering`. Of course, all of this is done automatically, you only need to use `YourItem.objects.all()` to get the items in an ordered way. Update: Now you can call your custom managers `object` as long as the default manager (the one that is defined first) still returns all objects. This Mix-in absolutely needs to be able to access all elements saved. In case you find any errors just write a comment, updated versions are published here from time to time as new bugs are found and fixed.
First off: This snippet is more or less obsoleted by [snippet #259](/snippets/259/). The way that snippet #259 uses feels cleaner and more usable. It is basically the same code but the magic works a little bit different. In case you prefer this way, I've left this snippet as-is. Maybe you know this problem: you have some objects in your database and would like to display them in some way. The problem: the Django ORM does not provide any way to sort model instances by a user-defined criterion. There was already a plug-in in SQLAlchemy called [orderinglist](http://www.sqlalchemy.org/docs/plugins.html#plugins_orderinglist), so implementing this in Django was basically not a big deal. Usage is (due to use of meta-classes) quite simple. It is recommended to save this snippet into a separate file called `positional.py`. To use it, you only have to import `PositionalSortMixIn` from the `positional` module and inherit from it in your own, custom model (but *before* you inherit from `models.Model`, the order counts).
25 snippets posted so far.