Re: Proposal: A diagram showing Class Based View inheritance and mixins.

[Meshy]

Copied from the related thread on reddit:

"the folks at ccbv.co.uk have been looking to build some sort of diagram..."

We have indeed!

In fact, in response to excitement generated by this thread, I've shipped 
our best version so far. To see it: go to any class on ccbv (eg 
http://ccbv.co.uk/TodayArchiveView/) and click the "Hierarchy diagram" link 
towards the top right.

This feature is still a work in progress, and hopefully will show 
attributes/methods soon (and be better integrated into the page). For the 
moment, I hope this keeps everyone happy!

Meshy `:D`.

On Tuesday, August 20, 2013 9:56:56 AM UTC+1, George Hickman wrote:
>
> Seth,
>
> This sounds like a great idea. I believe the folks behind ccbv.co.uk are 
> also trying to do something like this, maybe you could collaborate with 
> them?
>
> George
>
> On Monday, August 19, 2013 8:40:36 PM UTC+1, Seth Moon wrote:
>>
>> Such as one for each of the pink CBVs (CreateView, UpdateView, etc)? 
>> Yeah, I'll see what I can do.
>>
>> On Monday, August 19, 2013 12:54:29 AM UTC-7, Daniel Greenfeld wrote:
>>>
>>> Seth,
>>>
>>> I like it a lot. Is there any chance you can provide a focused version 
>>> per Class-Based View?
>>>
>>> Daniel Greenfeld
>>>
>>> On Sunday, August 18, 2013 10:03:59 PM UTC+2, Seth Moon wrote:
>>>>
>>>> I believe it would be beneficial to the Django developers and users if 
>>>> the documentation included a diagram showing the complete structure of how 
>>>> Class Based Views get their functionality. This would be a relatively 
>>>> simple diagram that shows the classes each generic view inherits from. The 
>>>> reason I am proposing this is because the current state of Generic Class 
>>>> Based Views is too complex for many people, myself included, with some 
>>>> views inheriting from 9 other classes (CreateView, UpdateView) down a long 
>>>> chain of both single and multiple inheritance. This would also enable 
>>>> people to gain a deeper understanding of why the Views are structured the 
>>>> way they are, and encourage people to explore the available BaseViews and 
>>>> mixins in order to assemble more customized applications without having to 
>>>> reinvent the wheel.
>>>>
>>>> I posted this on the Django Reddit 
>>>> community<http://www.reddit.com/r/django/comments/1kkl2t/a_diagram_showing_the_entire_django_class_based/>with
>>>>  relative success being the top post. There is a 
>>>> DIA <https://projects.gnome.org/dia/> diagram file and SVG available 
>>>> on a Google Drive 
>>>> folder<https://drive.google.com/folderview?id=0B4OX1EeVEeoKQWtQNF9ZMUpMOVE>that
>>>>  is publicly accessible for you to download and modify. Version 3 is 
>>>> the most current revision and differs extensively from what I originally 
>>>> posted on Reddit.
>>>>
>>>> A preview of the diagram can be seen below (It's a fairly large image):
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Class based views: A standard hook for http-method-independent code (and a proposal for an init() method)

[Meshy]

Marc and I have been using a mixin to override `dispatch()` with this 
functionality. He has an ongoing pull request on 
django-braces<https://github.com/brack3t/django-braces/pull/8>with the code. I 
hope this can be useful to some of you.

Meshy.

On Wednesday, October 31, 2012 9:49:26 AM UTC, Diederik van der Boor wrote:
>
> Hi,
>
> Please allow me to add my €0.02.
> In a large project I've experienced a similar issue; and we solved it in a 
> slightly different way.
> What we also noticed was:
> - overriding dispatch(), get() or post() wasn't good enough anymore.
> - the views need some initialization moment before their workflow (in 
> get/post of the base classes) start.
>
> What we ended up with is this base class (simplified a bit):
> https://gist.github.com/3985939
>
> *I seriously propose having such init() function in the Django views.*
> Mind you, that took a heated debate in the organization I was contacted 
> for, so please allow me to explain to context here.
> I think we've found a missing cornerstone in the way the class based views 
> are structured, and there is an easy fix.
>
> *What is the problem with overriding dispatch()?*
> When overriding dispatch(), get() or post() the flow is always:
>
> def dispatch(self, request, *args, **kwargs):
> # my code here.
> return super(…).dispatch(request, *args, **kwargs)
>
> The same also applies to get() and post().
> In other words, the last deriving class on top of the inheritance chain is 
> always initializing first before it's base classes.
> It can't rely on a base class to do some initialization.
>
> With our permission check in the base class' dispatch() method, anything 
> deriving from that effectively
> couldn't override dispatch() anymore because that would run before the 
> permission check.
>
> *How does the init method fix this?*
> By doing a self.init() in the top-most dispatch() method, each class in 
> the inheritance chain has a chance to fetch the objects it needs to have.
>
> That code can be written as:
>
> def init(self):
> super(..).init()
> # my code here.
>
> Now, the base class can initialize, then the deriving class.
> With a larger inheritance chain, this behavior becomes crucial.
> Each class can build upon what the other has prepared already.
>
>
> All of a sudden, we could do things like this:
>
> class PhotoListView(TabbedListView):
> """
> Contents of an photo album; a list of photo's.
> """
> model = Photo
>
> template_name = "photoalbum_album.html"
> permission_class = permissions.PhotoAlbumViewPermission
>
> def init(self):
> super(PhotoListView, self).init()
> self.photoalbum = get_object_or_404(PhotoAlbum, 
> pk=self.kwargs['pk'])  # parent object that filters the list
>
> def get_queryset(self):
> return super(PhotoListView, 
> self).get_queryset().in_album(self.photoalbum)
>
> def get_context_data(self, **kwargs):
> context = super(PhotoListView, self).get_context_data(**kwargs)
> context['photoalbum'] = self.photoalbum
> context['can_delete'] = self.is_authorized_for(PhotoDeleteView)
> return context
>
> This is a list view for photo's, and it's limited to a current photo album.
> The alternative is making a DetailView, and putting the photo's somewhere 
> in get_context_data() and thereby loose what the list view has to offer.
> Now we can just state it's a list view (which it is), and introduce the 
> filter easily.
>
> Without the init() method, you're probably knotting that somewhere in the 
> get_queryset() and get_context_data(),
> without having a clear path of that's happening. Thanks to the simple 
> init() method is all remains clean.
>
>
> *Some background of our use-case*
> The project is made for health care and privacy must be fully guaranteed.
> Hence, all views have to implement a permission check, which we wanted to 
> have in the base class.
> The only place to hook things up, was before the super call to 
>  dispatch(), otherwise the view already executed.
>
> At the same time, the permission check needs information from things like 
> "self.object", and the URL kwargs.
> That's because the permission check is role based; clients only see their 
> views, counselors may inspect their clients, etc..
> Implementing the check half-way in the regular get() and post() workflow 
> wasn't an option as it's easy to miss.
>
> With the init() method, we allow the view to initialize, and fetch all 
> objects, s

Proposal: unique by default on SlugFields

[Meshy]

Perhaps it's just me, but I've very rarely wanted a SlugField that wasn't 
unique. Would this not be a sensible default? I realise that a lot of apps 
will rely upon this default, but objectively speaking would this not be 
better? Perhaps this change would be appropriate for django 2.0.

At the moment, slug = models.SlugField()creates a non-unique field, and if 
you want it to be unique, then you must add unique=True. I feel this is 
wrong.

It seems to me that unique should be default, and if you don't want a 
unique slug, you should explicitly state that:
slug = models.SlugField(unique=False)

I've added an issue on the tracker for this: 
https://code.djangoproject.com/ticket/18525

I realise this may be a contentious issue...or that I may even get shot 
down in flames on this one ;P Go easy on me! :)

What do you all think?

Charlie.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/wb1YDBfDUO4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django's CVB - Roadmap?

[Meshy]

Still sounds like an issue with the docs to me, and while they do still 
have some issues, I'm a big supporter of the CBVs. 

I've posted this here before, but http://ccbv.co.uk/ really helps cut out 
most of the pain of the "looking through the source code" stage of 
understanding the CBVs because it squashes the class hierarchy and allows 
you to "see the wood for the trees" as it were. There are UX issues and 
even the odd bug, but it helps. In other words: it's a work in progress, 
but until the docs are fixed, I think it's a very useful 
resource. Disclaimer: I was involved in creating it, but it's 
not-for-profit, and there for everyone to use.

I would really like to get involved in getting the docs to the stage where 
they display something more similar to this, so if you know how I could do 
that, I'd really like to know.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/I80VlL1c89UJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Awkwardness of overriding View.dispatch for method-agnostic request-handling

[Meshy]

I agree that there is a need for this -- it has come up several times for 
me now -- however, I prefer my proposal (pretty printed here: 
https://gist.github.com/1957251 , code below...) mentioned in the topic 
"Class based views: A standard hook for http-method-independent code" 
(https://groups.google.com/d/topic/django-developers/7c7aI-slGNc/discussion).

Instead of separating the handler, I proposed a prepare_view method.

def dispatch(self, request, *args, **kwargs):
if request.method.lower() in self.http_method_names:
handler = getattr(self, request.method.lower(), 
self.http_method_not_allowed)
else:
handler = self.http_method_not_allowed
self.prepare_view(request, handler, *args, **kwargs)
return handler(request, *args, **kwargs)

def prepare_view(self, request, handler, *args, **kwargs):
"""Set local variables before the dispatch handler is called."""
self.request = request
self.args = args
self.kwargs = kwargs

On Wednesday, April 11, 2012 7:12:51 AM UTC+1, schinckel wrote:
I agree: but this means that the actual dispatcher (that, according to the 
comments,
"dispatch[es] to the right method", is called handle(), rather than 
dispatch.


Perhaps the assignation of request/args/kwargs could happen before dispatch 
is 
called?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/yMkwcy8ehnkJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Charlie "meshy" Denton]

Firstly, please excuse my double post: I didn't realise posts are vetted, 
so I thought it had been lost.

The very significant advantage of this being a hook (instead of overriding 
dispatch) is that it allows you to call methods that require dispatch to 
have already set variables (eg: self.kwargs) on the class before the 
handler (eg: get()) is called.

Normally I have no problem overriding dispatch, but this has come up a 
couple of times for me, and overriding dispatch in this way has felt ugly.

On Thursday, 1 March 2012 18:38:08 UTC, Marc Tamlyn wrote:
>
> Hi all,
>
> Apologies if this has been raised before. I've had a look around and can't 
> find a good way of doing this with the current code.
>
> I regularly have views which rely on some custom code which runs some 
> sanity checking on the request and is independent of method. As an example, 
> consider a view which creates an object related to a parent. This is easily 
> achievable by overriding the form_valid method of CreateView and excluding 
> the foreign key from the form. However, the view should return a 404 if the 
> related object specified by the url does not exist. Written as a non class 
> based view, the natural flow is to try to load the parent object from the 
> database, handle it as necessary, and then split paths depending on whether 
> we have a get or post. It is currently very difficult to emulate this 
> without duplication of some sort.
>
> My proposal is that we add a process_request (or similar name) method 
> which is called by the dispatch method immediately before the method 
> handler is called. (i.e. 
> here).
>  
> This would then allow pre-processing and sanity checking of the request 
> object, using the args, kwargs and request that have been saved on the 
> class, before delegating off the the respective views. The method should 
> return None or an HttpResponse subclass. If it returns something, then we 
> return that directly from the dispatch method.
>
>
> I can supply some code (my proposal is pretty simple I think) but I 
> thought I'd open it up for discussion first.
>
> Marc Tamlyn
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/imEZWRGm8ygJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Charlie "meshy" Denton]

I would like to see something like this too. I my suggestion is here: 
https://gist.github.com/1957251

This method has two advantages:
1. You can modify the request, args, and kwargs before they get saved to 
the view.
2. You can execute code after request, args, and kwargs are saved but 
before the dispatch handler is called.
3. You can save extra variables to self as required

I expect 2 is probably the most common use case.

Meshy.


On Thursday, March 1, 2012 6:38:08 PM UTC, Marc Tamlyn wrote:
>
> Hi all,
>
> Apologies if this has been raised before. I've had a look around and can't 
> find a good way of doing this with the current code.
>
> I regularly have views which rely on some custom code which runs some 
> sanity checking on the request and is independent of method. As an example, 
> consider a view which creates an object related to a parent. This is easily 
> achievable by overriding the form_valid method of CreateView and excluding 
> the foreign key from the form. However, the view should return a 404 if the 
> related object specified by the url does not exist. Written as a non class 
> based view, the natural flow is to try to load the parent object from the 
> database, handle it as necessary, and then split paths depending on whether 
> we have a get or post. It is currently very difficult to emulate this 
> without duplication of some sort.
>
> My proposal is that we add a process_request (or similar name) method 
> which is called by the dispatch method immediately before the method 
> handler is called. (i.e. 
> here<https://github.com/django/django/blob/master/django/views/generic/base.py#L68>).
>  
> This would then allow pre-processing and sanity checking of the request 
> object, using the args, kwargs and request that have been saved on the 
> class, before delegating off the the respective views. The method should 
> return None or an HttpResponse subclass. If it returns something, then we 
> return that directly from the dispatch method.
>
>
> I can supply some code (my proposal is pretty simple I think) but I 
> thought I'd open it up for discussion first.
>
> Marc Tamlyn
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/z63TmT57twQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Charlie "meshy" Denton]

I'd like to see something like this too: my suggestion is here:
https://gist.github.com/1957251

This implementation also allows you to play with the request, args and
kwargs before they are saved on the model.

On Mar 1, 6:38 pm, Marc Tamlyn  wrote:
> Hi all,
>
> Apologies if this has been raised before. I've had a look around and can't
> find a good way of doing this with the current code.
>
> I regularly have views which rely on some custom code which runs some
> sanity checking on the request and is independent of method. As an example,
> consider a view which creates an object related to a parent. This is easily
> achievable by overriding the form_valid method of CreateView and excluding
> the foreign key from the form. However, the view should return a 404 if the
> related object specified by the url does not exist. Written as a non class
> based view, the natural flow is to try to load the parent object from the
> database, handle it as necessary, and then split paths depending on whether
> we have a get or post. It is currently very difficult to emulate this
> without duplication of some sort.
>
> My proposal is that we add a process_request (or similar name) method which
> is called by the dispatch method immediately before the method handler is
> called. (i.e. 
> here).
> This would then allow pre-processing and sanity checking of the request
> object, using the args, kwargs and request that have been saved on the
> class, before delegating off the the respective views. The method should
> return None or an HttpResponse subclass. If it returns something, then we
> return that directly from the dispatch method.
>
> I can supply some code (my proposal is pretty simple I think) but I thought
> I'd open it up for discussion first.
>
> Marc Tamlyn

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.