Django Cheat Sheet

[John Sutherland]

Hi all,

Firstly, sorry for the cross-post.

My employer, Mercurytide [1], as some of you may have seen in the
past, publishes white-papers on a monthly basis. This month it's
another Django themed one: a Django cheat sheet:

<http://www.mercurytide.com/whitepapers/django-cheat-sheet/>

We've spent a fair bit of time on it and would really appreciate the following:

1. That you download it; try it out and enjoy it!
2. Give us feedback, we know it's not going to be perfect first time,
so let us know: in...@mercurytide.com
3. You publicise it: it would be awesome to get it on the digg front
page [2]; but put it on your blog, your del.icio.us or where ever...

Cheers,
John.

[1] <http://www.mercurytide.com/>
[2] <http://digg.com/programming/Django_cheat_sheet>

--
john.su...@gmail.com

[lbolo...@gmail.com]

On Feb 13, 11:24 am, "John Sutherland" <john.sutherl...@gmail.com>
wrote:

> My employer, Mercurytide [1], as some of you may have seen in the
> past, publishes white-papers on a monthly basis. This month it's
> another Django themed one: a Django cheat sheet:

Good job John, thanks.

Lorenzo

[Jacob Kaplan-Moss]

On 2/13/07 4:24 AM, John Sutherland wrote:
> My employer, Mercurytide [1], as some of you may have seen in the
> past, publishes white-papers on a monthly basis. This month it's
> another Django themed one: a Django cheat sheet:

This is awesome, John -- many thanks for putting it together :)

Jacob

[Lars Stavholm]

John Sutherland wrote:
> Hi all,
>
> Firstly, sorry for the cross-post.
>
> My employer, Mercurytide [1], as some of you may have seen in the
> past, publishes white-papers on a monthly basis. This month it's
> another Django themed one: a Django cheat sheet:
>
> <http://www.mercurytide.com/whitepapers/django-cheat-sheet/>
>
> We've spent a fair bit of time on it and would really appreciate the following:
>
> 1. That you download it; try it out and enjoy it!
> 2. Give us feedback, we know it's not going to be perfect first time,
> so let us know: in...@mercurytide.com
> 3. You publicise it: it would be awesome to get it on the digg front
> page [2]; but put it on your blog, your del.icio.us or where ever...

Brilliant!
/L

[Marc Fargas Esteve]

wow!

[Geert Vanderkelen]

Hi John,

On 13 Feb 2007, at 11:24, John Sutherland wrote:

>
> Hi all,
>
> Firstly, sorry for the cross-post.
>
> My employer, Mercurytide [1], as some of you may have seen in the
> past, publishes white-papers on a monthly basis. This month it's
> another Django themed one: a Django cheat sheet:
>
> <http://www.mercurytide.com/whitepapers/django-cheat-sheet/>

Awesome! Thanks for sharing this!
If only I had that this morning while on the train! :)

Cheers!

Geert

--
Geert Vanderkelen
http://some-abstract-type.com

[Benedict Verheyen]

John Sutherland schreef:

> Hi all,
>
> Firstly, sorry for the cross-post.
>
> My employer, Mercurytide [1], as some of you may have seen in the
> past, publishes white-papers on a monthly basis. This month it's
> another Django themed one: a Django cheat sheet:

Super John, very useful !

Thanks,
Benedict

[Picio]

Many many thanks, It helped me find the "js" admin feature !
I've not seen It before !
Useful!
Picio

2007/2/13, Benedict Verheyen <benedict...@gmail.com>:

[Tim Chase]

> a Django cheat sheet:
>
> <http://www.mercurytide.com/whitepapers/django-cheat-sheet/>
>
> We've spent a fair bit of time on it and would really appreciate the following:
>
> 1. That you download it; try it out and enjoy it!

Good stuff. Had to squish it from A4 to 8.5x11 (rolls eyes at
the silly American paper metric when A4 is so much more asthetic)
but it came out legibly.

> 2. Give us feedback, we know it's not going to be perfect first time,
> so let us know: in...@mercurytide.com

I noticed that ForeignKey, OneToOne, and ManyToMany field types
were missing...I don't know if there's too much detail required
for those to smash them into what little space you have left, but
they're certainly hairier corners that it would be helpful to
have on a cheat-sheet. I remember hearing rumors that OneToOne
may be deprecated, but I can't find any evidence to back that up.

Perhaps if you need the space, a 2nd page could contain FK and
M2M (and perhaps O2O) as well as the date/time formatting codes
that the sheet currently only references. The whole thing could
then be printed 2-sided and laminated to prevent food & beverage
damage ;)

Just my ponderings. Still helpful even without the above
changes/additions.

-tkc

[Rob Hudson]

Very cool.

I agree with another poster, adding FK and M2M and their options would
be a nice addition if there is room.

Minor nit... It says for version 0.95 yet there is a single template
filter with footnote "In development version only." It seems like you
might as well remove that.

This also reminds me of a question I've been meaning to ask...

Is there any reasoning to when an admin class option is a list and
when it is a tuple? I tend to default to tuple since I don't want to
have to go look it up every time. Can admin options be standardized
to tuples across the board to make it easy?

[James Bennett]

On 2/13/07, Rob Hudson <trebor...@gmail.com> wrote:
> I agree with another poster, adding FK and M2M and their options would
> be a nice addition if there is room.

Might be worth doing up multiple sheets, kind of like YUI does with
their components.

> Is there any reasoning to when an admin class option is a list and
> when it is a tuple? I tend to default to tuple since I don't want to
> have to go look it up every time. Can admin options be standardized
> to tuples across the board to make it easy?

Not really. Anything you can do to a tuple (which is, basically,
iterate over it, slice it and access specific items out of it) you can
also do to a list. A tuple is just a little bit more efficient when
you know you're dealing with something that isn't/shouldn't be
mutable.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Rob Hudson]

> Not really. Anything you can do to a tuple (which is, basically,
> iterate over it, slice it and access specific items out of it) you can
> also do to a list. A tuple is just a little bit more efficient when
> you know you're dealing with something that isn't/shouldn't be
> mutable.

Actually, I think "list_per_page" should be an integer, not a list as
it is on the cheat sheet.

If so, that means only the js option is a list. Which means
everything that has a multiple option list is a tuple already, with
the exception of the js list.

For some reason I thought ordering took a list.

-Rob

[Matt]

Cheers for all the feedback guys. Here's a reply to your questions so
far.

As Malcolm Tredinnick pointed out in a private reply (and James Bennet
here), Django doesn't mind whether you pass it a tuple or a lists; one
can be substituted for the other. I think I'll remove this
distinction in the next issue.

For reasons of space I left out details on foreign keys, many-to-many
relationships and, because they're undergoing change, one-to-one
relationships. They seem to be popular enough that I'll look at
adding a second page to include them.

I was a little naughty and included some functionality only available
in the development version. I followed the docs in this respect, but
I guess for consistency I should remove this.

I want to try and keep it up-to-date: when 0.96 is released I'll find
time to issue a new version with changes from the newforms-admin
branch et al.

Rob Hudson's right: list_per_page should be an integer, not a list. I
knew I'd miss something! I'll change that in the morning.

Does anyone have any requests for what to include on a second page?
(The biggest internal request has been for an example of the fields
options in the Admin inner class - something we're forever looking
up.)

A loud 'Thank you!' should go to the designer, Ed, for managing to
make all that text look presentable. Cheers, Ed.

M.

--
Matt Riggott.
Dictated but not read.

[Honza Král]

On 2/13/07, Matt <matt.r...@gmail.com> wrote:
>
> Cheers for all the feedback guys.

Well, cheers to you in the first place... ;)

Here's a reply to your questions so
> far.
>
> As Malcolm Tredinnick pointed out in a private reply (and James Bennet
> here), Django doesn't mind whether you pass it a tuple or a lists; one
> can be substituted for the other. I think I'll remove this
> distinction in the next issue.
>
> For reasons of space I left out details on foreign keys, many-to-many
> relationships and, because they're undergoing change, one-to-one
> relationships. They seem to be popular enough that I'll look at
> adding a second page to include them.

there still is some confusion (judging by the questions in
django-users) about related models lookup, so the combination of
related fields (FK, M2M and 1to1) and db_api should be very useful...

>
> I was a little naughty and included some functionality only available
> in the development version. I followed the docs in this respect, but
> I guess for consistency I should remove this.
>
> I want to try and keep it up-to-date: when 0.96 is released I'll find
> time to issue a new version with changes from the newforms-admin
> branch et al.

great news

> Rob Hudson's right: list_per_page should be an integer, not a list. I
> knew I'd miss something! I'll change that in the morning.
>
> Does anyone have any requests for what to include on a second page?
> (The biggest internal request has been for an example of the fields
> options in the Admin inner class - something we're forever looking
> up.)

perhaps a list of db_api functions and field lookups? also a list of
form fields and widgets would be useful, if you want to stick with
stable features, what about generic views - including their context
and parameters.

> A loud 'Thank you!' should go to the designer, Ed, for managing to
> make all that text look presentable. Cheers, Ed.

Thanks Ed ;)

>
> M.
>
> --
> Matt Riggott.
> Dictated but not read.
>
>
> >
>

--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585

[Julian Romero]

On 2/13/07, John Sutherland <john.su...@gmail.com> wrote:

Hi all,

Firstly, sorry for the cross-post.

My employer, Mercurytide [1], as some of you may have seen in the
past, publishes white-papers on a monthly basis. This month it's
another Django themed one: a Django cheat sheet:

<http://www.mercurytide.com/whitepapers/django-cheat-sheet/>

We've spent a fair bit of time on it and would really appreciate the following:

1. That you download it; try it out and enjoy it!
2. Give us feedback, we know it's not going to be perfect first time,
so let us know: in...@mercurytide.com
3. You publicise it: it would be awesome to get it on the digg front
page [2]; but put it on your blog, your del.icio.us or where ever...

Great work, thanks.
A couple suggestions here:
 * if you give away the original format (it seems it's InDesign) others can improve, adapt, make new versions and you will get more publicity (add a by-attribution license)
 * move the legend to your web site, symbols are quite obvious and you will save lot of space for additional stuff like usual command line options or whatever
--
Julián

[Aidas Bendoraitis]

I found one small mistake. CommaSeparatedIntegerField doesn't have
auto_now and auto_now_add, so they should be removed from the
appropriate place in the cheet sheet.

Regards,
Aidas Bendoraitis [aka Archatas]

[Matt]

On Feb 13, 10:24 am, "John Sutherland" <john.sutherl...@gmail.com>
wrote:
> <http://www.mercurytide.com/whitepapers/django-cheat-sheet/>

Issue 2 has been published:

* The list_per_page Admin class option is now marked as an integer,
not as an list.
* CommaSeparatedIntegerField no longer has auto_now and auto_now_add
parameters.
* The distinction between lists and tuples has been removed.