Yes, definitely! That was something I had in mind coming up with the
concept. The "Conditions" themselves are written with no knowledge of and
have no relation to class-based views, they simply give a pass or a fail
given certain conditions.
On Friday, March 18, 2016 at 10:56:46 PM UTC+8, Collin Anderson wrote:
>
> Hi Connor,
>
> I personally usually avoid class based views whenever possible and stick
> to function based views whenever possible. Would these Conditions be usable
> within function based views too?
>
> Thanks,
> Collin
>
>
> On Thursday, March 17, 2016 at 8:00:16 AM UTC-4, Connor Boyle wrote:
>>
>> 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 in core Django (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. This is enabled by one other key difference between the two: my
>> proposal's separation between the evaluate() layer–the one that's generally
>> overridden by the developer or by common usage sub-classes–and the run()
>> layer–which calls the evaluate() layer after picking which keyword
>> arguments it should pass to it.
>>
>> On Thursday, March 17, 2016 at 1:31:37 AM UTC+8, Ryan Hiebert wrote:
>>>
>>>
>>> On Mar 16, 2016, at 11:55 AM, Connor Boyle <cbo...@macalester.edu>
>>> 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. [snip]
>>>
>>> 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.
>>>
>>>
>>> It seems like a neat idea, and reasonably well thought out, though I
>>> don't have the standing needed to speak to its viability as a GSOC project
>>> or for inclusion in Django. I'd be interested to see a write-up comparing
>>> this with Django Rest Framework's Permissions, which seem pretty similar in
>>> concept. http://www.django-rest-framework.org/api-guide/permissions/
>>>
>>
--
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/f56e5ac5-4159-4d09-939f-7e7e2adfb69e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
