Activity timeline
March 10, 2009
January 11, 2009
December 30, 2008
December 14, 2008
December 12, 2008
Books by Friends
A list of books in which I hear the voices of the people who wrote them. Probably because I've already met them. :)
Chapters 10 and 11 are the meat and potatoes. These are usually the chapters that I love to read and re-read. Lots of code examples. I took a lot more time on these sections, keeping one of my projects open as I read to not only learn, but compare. Again there are a lot of little timesavers in this book, especially in these final two chapters.
And now I'm done.
Overall, I loved the book. I learned a lot of things I don't think I would have just grazing around the documentation, but Marty applied concepts in ways that's beyond the scope of what documentation is supposed to do. From basic Python to exploring the interiors of the File handling and storage system, he really does a great job at explaining things in terms that even intermediates like me can understand.
There are very strong tutorials, like ...
davej replies...
Thanks for the review Bryan. You've persuaded me to order it.
Pro Django is full of so many awesome little bits that I never would have found otherwise. Example:
class Property(models.Model):
LISTED = 1
PENDING = 2
SOLD = 3
STATUS_CHOICES = (
(LISTED, 'Listed'),
(PENDING, 'Pending Sale'),
(SOLD, 'Sold'),
)
Marty simplifies lines 2-4 by doing this:
class Property(models.Model):
LISTED, PENDING, SOLD = range(3)
STATUS_CHOICES = (
(LISTED, 'Listed'),
(PENDING, 'Pending Sale'),
(SOLD, 'Sold'),
)
This is something I think I'll never get. In this example, Marty uses a OneToOneField to connect his Contact model to auth.User, but many times I've seen a ForeignKey to do the same thing. I've never quite understood the differences between the two and they're probably both very acceptable ways of doing the same thing. I've just been very interested to know which one is used more often.
from django.db import models
from django.contrib.auth.models import User
from django.contrib.localflavor.us import models as us_models
class Contact(models.Model):
user = models.OneToOneField(User)
phone_number = us_models.PhoneNumberField()
address = models.CharField(max_length=255)
city = models.CharField(max_length=255)
state = us_models.USStateField()
zip_code = models.CharField(max_length=255)
class Meta:
ordering = ('user__last_name', 'user__first_name')
def __unicode__(self):
return self.user.get_full_name()
bjornkri replies...
OneToOne means each Contact can only be connected to one User, and each User only one Contact. If you'd use a ForeignKey however, each User could have a set of Contact objects. Using Readernaut as an example, it would make sense to make the information in your Profile OneToOne: you only have one Profile, and no one shares it with you. But that Note you wrote would have a ForeignKey. Only you authored that Note, but that doesn't mean it's the only Note you can have. Books on the other hand are ManyToMany, since each Book can belong to many Users, and each User can have many Books. Hope that makes sense :P
Bryan replies...
Yes, it makes perfect sense. Thank you for taking the time to explain that to me. :)
patrick replies...
Just a newbie, but if I recall correctly one of the reasons why so many used ForeignKey was that prior to the QuerySet-Refactor/Django 1.0, OneToOneField wasn't really working the way the Core Devs wanted and a warning was placed against it: From the old docs: "The semantics of one-to-one relationships will be changing soon, so we don't recommend you use them. If that doesn't scare you away, keep reading."
I wish that this page went a little further into how to effectively use caching (caching QuerySets, etc.), but that could be classified as being beyond the scope of the book. Still though, it would have been nice. :)
We'll see if I run into it later.
The following shows you I never studied programming.
I've looked at C code before and kept seeing things like signed vs unsigned and I never knew what the hell that meant. Only now, on this page, do I get it. Signed integers can be negative (hence the negative "sign") and unsigned integers cannot.
Thank you Marty.
The code excerpt on this page seems to be either derived from or used as a base for this project -- http://code.google.com/p/django-signe...
Either way, this is definitely something that Django should take care of by default. I'll definitely be adding the middleware to my social projects.
Gulopine replies...
Derived from. And signed cookies are on the maybe list for Django 1.1, so we'll see what happens. :)
Enabling User- Submitted Themes has to be one of my favorite parts of the book so far. It is one of the best tutorial pieces in the book (again, so far) and definitely something I'll be using for multiple upcoming projects. Not only is the code great to look at, I love how Marty takes the different ways of going about this challenge into consideration.
For this particular view, a few things can be factored out in this way. The model doesn’t need to be known in advance and the view should also be able to work with a QuerySet so that a particular URL could operate on a limited set of data. Also, the field name shouldn’t be hard-coded, and the template name should be provided outside the view.
from django.shortcuts import render_to_response
from django.template import RequestContext
def show_object(request, id, model, template_name):
object = model._default_manager.get(pk=id)
context = RequestContext(request, {'object': object)})
return render_to_response(template_name, context)
I skimmed through most of Chapter 3, mostly because I don't think I'll ever need to access a lot of the functionality that lies within _meta, nor will I be creating my own fields anytime soon. However, I'll definitely reference it.
Bryan replies...
Yes, it makes perfect sense. Thank you for taking the time to explain that to me. :)