Hello everyone,
I've updated my proposal
<https://gist.github.com/cascadianblue/2856bea128dd1b3f4d0f> fairly
dramatically (different link than before). I've written a lot of code to
show just how much of a mess the problem I'm trying to solve is, but
unfortunately haven't quite had time to finish it (and therefore haven't
added it at all), so the Example section is rather thin and might not be as
convincing as it will be when I've add those in. It's also missing a couple
of sections on potential hooks that I haven't quite finished writing.
What I'm really hoping to get feedback on is the "Implementation"
section–particularly the "Core", so please everyone critique at will.
On Friday, March 18, 2016 at 11:08:57 PM UTC+8, Connor Boyle wrote:
>
> I'm still working on fleshing out how specifically to add them into
> function-based views–what code the API should provide to automate or
> semi-automate the auth-related functionality once a Condition has failed
> (redirect to login, etc.). I'll get that in my proposal ASAP, but if you
> have any particular suggestions or (more likely) warnings, I'd really
> appreciate it.
>
> On Friday, March 18, 2016 at 11:01:27 PM UTC+8, Connor Boyle wrote:
>>
>> 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/029964ca-b83d-4f29-8bcb-f33ce6d5c654%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
