Class Based Views tutorials

46 views
Skip to first unread message

Brad Rice

unread,
Jan 6, 2015, 1:49:44 PM1/6/15
to django...@googlegroups.com
Does anyone have a recommendation for intermediate reading to understand Class Based Views? It seems most of the Django books were written when function based views were prevalent. I'm still having trouble understanding what the differences are between CreateView and UpdateView and what Meta is as well as slug_field and pk. Perhaps my issue is understanding Object oriented python? I wish there were some tutorials or cookbooks that offer better understanding.

Sergiy Khohlov

unread,
Jan 6, 2015, 2:39:49 PM1/6/15
to django-users
Diff is simple : UpdateView is using for changing already created object. CreateView is using  for creating new object.
I have few simpleast class for your request. But I have not  commented yet. 

Many thanks,

Serge


+380 636150445
skype: skhohlov

On Tue, Jan 6, 2015 at 3:49 PM, Brad Rice <brad...@gmail.com> wrote:
Does anyone have a recommendation for intermediate reading to understand Class Based Views? It seems most of the Django books were written when function based views were prevalent. I'm still having trouble understanding what the differences are between CreateView and UpdateView and what Meta is as well as slug_field and pk. Perhaps my issue is understanding Object oriented python? I wish there were some tutorials or cookbooks that offer better understanding.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7fac53a2-7ff6-488f-903f-ed46edf15deb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Brad Rice

unread,
Jan 6, 2015, 4:45:37 PM1/6/15
to django...@googlegroups.com
When I was working with formsets, it seemed to me best to just use a single UpdateView with post and get functions defined rather than having a separate CreateView class. Seemed to handle both create and update ok.

Jim Wombles

unread,
Jan 6, 2015, 5:09:13 PM1/6/15
to django...@googlegroups.com
Two Scoops of Django is definitely the book you are looking for. I don't know if it's out for 1.7 yet, but I purchased the book for Django 1.6 and it covers l of the best practices that you won't read about just from the Django docs.

Sergiy Khohlov

unread,
Jan 6, 2015, 8:40:29 PM1/6/15
to django-users

Add function get() and post() to the view class.  Code is near to same not class view

6 січ. 2015 18:45, користувач "Brad Rice" <brad...@gmail.com> написав:

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/703f0448-2152-418a-9466-4e87e1226b62%40googlegroups.com.

Lachlan Musicman

unread,
Jan 6, 2015, 9:02:00 PM1/6/15
to django...@googlegroups.com
To answer the unanswered q's:

Meta is where you define things about the class, but are not in the
class. If you can imagine a space created that *all* classes would
need, mine as well as yours, this is in Meta. It's "Meta". IE. How
does this class sort? Should a couple of fields be "unique together",
do you want it's table to have a particular name in the database -
things that have sensible defaults, are common across all classes, but
can be changed.

"pk" is also known as "id" and stands for "primary key". This is a
fundamental of relational databases - every tuple has an identifying
element, usually table name and pk/id.

In days gone by we used to have things UUID (universally unique id) or
GUID (Globally Unique Identifier) - and they tended to look like this
a603732f-2314-4a34-b06e-3f016dd7a54c

Django largely hides the pk away, so that you don't need to worry
about it, although it can be useful in day to day use if you don't
have a particular identifying need - the biggest problem with a long
string of hex is that it's hard to look at it and say "oh, that's
John's tuple".

the slug_field is an URL shortener that makes identifying an object
via URL easier.

eg: John's tuple:

(without slug, with ugly uuid)
http://myapp.com/a603732f-2314-4a34-b06e-3f016dd7a54c

or

(with slug = name)
http://myapp.com/john-smith

Originating from newspaper urls, it's why you now get the easier to recall:

http://boingboing.net/2014/11/16/band-releases-unplayable-glass.html

It's not only got a slug, but also the date - so should there ever be
the need for another article about unplayable glass master discs, it
can still be unique (via Meta)

I hope that helps.
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/7fac53a2-7ff6-488f-903f-ed46edf15deb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
------
"We are at once both obnoxious and indispensable." - John Ngumi on the Kikuyu
in It's Our Turn To Eat, by Michela Wrong.
Reply all
Reply to author
Forward
0 new messages