My original inspiration actually was Django Rest Framework, but I wanted to show that I had actually thought it out and that it is indeed possible to implement (albeit not quite as cleanly as DRF does it). I'll try to finish a more detailed write-up of how they compare, but in short they are very similar. In terms of overall paradigm, the largest difference is that DRF's "permissions" are designed exclusively for being run given the request or the request and the result of get_object(). My proposal, on the other hand, would allow conditions to be written that don't require these arguments and in fact require other arguments, although it does provide appropriate sub-classes for these extremely common usage cases.
On Thursday, March 17, 2016 at 12:55:04 AM UTC+8, Connor Boyle wrote: > > I'm hoping to add a feature that I've thought Django has needed for a long > time, and thought that Google Summer of Code would be an excellent > opportunity for it. Basically, it would be an API for defining 'Conditions' > and applying them to Views. Common usages would include restricting views > based on whether a user is the owner of an object (as determined by a > ForeignKey), whether a group-style object has the capacity to add another > object to its members, whether the user has a certain permission, etc. > Though Django recently added some Auth-related mixins (e.g. > UserPassesTestMixin > <https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.mixins.UserPassesTestMixin>) > > that get the job done in simple situations, however the lack of separation > between view-related functionality and condition-evaluation code severely > limits their usability in more complex situations. > > My proposal <https://gist.github.com/cascadianblue/48af15d511ec67e54411> > is still not entirely done (no timeline and the implementation section > needs a lot of clarification), but it looks like time is getting fairly > tight so I figured I should reach out ASAP. I was particularly hoping to > get feedback on the part of my proposal where I assert that it is necessary > in the first place ('The Problem(s)'). > > Questions: > 1. How clear and convincing is the section describing what's wrong with > the current solution ('The Problem(s)')? Any criticisms on that section > would be very welcome. > 2. Are you or anyone you know interested in mentoring on this project? > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a925f325-1089-4eef-82f6-11bcc2ac89f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
