Blank is purely for validation and has nothing to do with the database constraints. If you want to prevent empty input just remove 'blank=True', surely?
Yep, I assumed that wasn't the case based on the blog post's goal of avoiding changing the schema (I thought blank=True must be adding a CHECK (column_name <> '') constraint or something).
The landing page for the book is very good. I specially like the call to action button. Good color choice, size, and font. I would add an additional button in the middle of the page. In the area where it says "This book covers the following and more:" (green background). In fact, everyone could use this as a good template to follow for programming books. Though they could also use your approach of a colorful cover to draw attention (it pops out in your blog), and ad placement in the blog (top of sidebar, next to the first paragraph of the post). The blog article also made me want to buy the book. This is a very well designed product campaign that is simply not spammy, and valuable. Even if I don't buy the book, I get value from reading the posts.
Have you tested other pricing strategies? Like $13.99 or $14.99? I think $14.99 would net you a slight bigger sale without a loss of sales. Though $13.99 might have them drop due to how people perceive the number 13 to be an undesirable number.
Yes. A thousand times yes. I think the reason more people don't do it this way is because the documentation emphasizes how declarative models, forms, admin classes, etc are, and people forget that it's all just Python.
I've had much more luck with WTForms than django forms. Specifically, the FormField method for decomposing common elements of multiple forms is much more pleasant to work with than trying to do something in Django.
This looks nice for when the fields in a form and model are identical, but in my experience that doesn't happen all that often.
For those wondering about 'the second bug', I'm going to suggest that it's the lack of
class Meta:
fields = ('only', 'whitelisted', 'fields')
which defaults the form to exposing all the model fields for modification, allowing naughtyness not unlike the Rails mass-assignment issues that cropped up a while back.
Or maybe the name field having blank=True, but no default value?
Nope! What you are talking about falls under "best practice" and not a bug. It's very good that you bring it up though! For what it's worth, every technical reviewer we had insisted that we cover the issue of fields vs excludes. :-)
Hey, I bought your book but I'm not sure I have the link to the latest version. The last version I had a link to was "tsd20130326.pdf" - is that the latest?