
Django's Architecture: The Good, The Bad, and The Ugly - rubygnome
https://speakerdeck.com/andrewgodwin/djangos-architecture-the-good-the-bad-and-the-ugly
======
makeramen
Someone should mark this (2011).

South provides stable and mature migrations for schema changes [1]

Custom Auth models are now available in Django 1.5 [2]

The templating language definitely needs some work, but it's slowly getting
better. I'd prefer them drop in Jinja2 but that's just me.

[1]
[http://south.readthedocs.org/en/latest/](http://south.readthedocs.org/en/latest/)

[2]
[https://docs.djangoproject.com/en/1.5/topics/auth/customizin...](https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#substituting-
a-custom-user-model)

~~~
mixmastamyk
Didn't I read South was being rewritten to be included in a future Django?

Also, how about defaulting to bootstrap for the homely-looking admin app?

~~~
airtonix
bootstrap is horrible and your suggestion doesn't address the problem.

~~~
manojlds
Bootstrap is ideal for internal admin interfaces

~~~
LoganCale
This is what I use it for, almost exclusively, and it works great for that
purpose.

------
jgj
Here's the video for folks who prefer sentences and context:
[http://www.youtube.com/watch?v=7KTVws3TiC0](http://www.youtube.com/watch?v=7KTVws3TiC0)

~~~
Udo
Thank you. Slides don't do anything for me, I think it's a very tiresome way
to make a point if there isn't at least a blog post or a video of the talk
somewhere.

------
mattchew
I don't like Forms/ModelForms.

It doesn't seem to be a common complaint, but I always end up fighting with
Forms when I try to use them. Too complicated, too confining, and too unique-
to-Django. I wish Django had gone with field helpers instead.

~~~
sashahart
I'm curious about 'field helpers,' can you point to a page or briefly describe
the difference?

~~~
mattchew
Sure, I mean helpers for the template/view that make it easier (syntax, data
binding, validations) to render a HTML form widget. Instead of defining your
form as a unit in app code, you manage the form fields in the view/template.
For my money, this is much more intuitive and flexible.

It's common in other web frameworks. At least Codeigniter, Ruby on Rails, and
ASP.NET MVC use this approach:

[http://ellislab.com/codeigniter/user-
guide/helpers/form_help...](http://ellislab.com/codeigniter/user-
guide/helpers/form_helper.html)

[http://guides.rubyonrails.org/form_helpers.html](http://guides.rubyonrails.org/form_helpers.html)

[http://msdn.microsoft.com/en-
us/library/dd410596(v=vs.100).a...](http://msdn.microsoft.com/en-
us/library/dd410596\(v=vs.100\).aspx)

------
csense
Those regular expressions desperately need refactored. Maybe like this:

    
    
       c = r"[-!#$%&'*+/=?^_`{}|~0-9A-Z]"
       dot_atom = r"{c}+(\.{c}+)*".format(c=c)
    
       c1 = r"[\001-\010\013\014\016-\037!#-\[\]-\177]"
       c2 = r"[\001-\011\013\014\016-\177]"
       quoted_string = r"'({c1}|\\{c2})*'".format(c1=c1, c2=c2)
    
       c = r"[A-Z0-9]"
       dash_something = r"(?:-*{c}+)".format(c=c)
       domain = r"(?:{c}+{dash_something}\.)+{c}{{2,6}}".format(c=c, dash_something=dash_something)
    
       email = "^({dot_atom}|{quoted_string})@{domain}$"
    

There's a typo in the original, which I fixed: \001-011 should be \001-\011.

------
anderspetersson
Django is a much better web framework now than it was 2 years ago.

------
gojomo
[2011]

The auth customization story has improved recently in 1.5, and the author of
this very presentation (Andrew Goodwin) is bringing support for schema changes
into the core with his post-South project:

[http://www.kickstarter.com/projects/andrewgodwin/schema-
migr...](http://www.kickstarter.com/projects/andrewgodwin/schema-migrations-
for-django)

~~~
thejosh
Almost 18,000 pounds is amazing.

It just shows that when developers need something (database migrations) they
are usually willingly to Kickstart something.

I hope these sorts of things continue for things that need to be done but
aren't actively worked on.

------
k_bx
For me, the worst thing about django is it's source code. Every time I have to
dig into some problem, I see really long functions with multiple abstraction
levels mixed, a lot of strange names and other code that is really hard to
read (ok, it's still python, so you still _can_ read everything after a bit of
tryings).

~~~
obviouslygreen
Not trying to be disparaging, but how much experience do you have working with
Python and the libraries that are built with it? I routinely hit the source to
see where things are going while working through stack traces or extending
built-ins, and while it's not always crystal clear, I've rarely gotten the
impression things were done in such a way as to be entirely unreadable or
unforgivably abstracted.

~~~
k_bx
I have lots of experience with python (>5 years, and +5 years of web-dev
before that) and I have no problem reading some of challenging source code out
there of course. I'm rather referring to quality of code itself from the
perspective of Robert Martin's "Clean Code". I can't remember concrete bits of
course, but it sure happened in past.

------
brokentone
Shows a LOT of maturity for a core dev on an open source project to discuss
the "bad" and "ugly" parts. Everything has them, but to pretend they don't
exist, or that they are features like some of the other CMS-y OSS people is
unhelpful.

~~~
MostAwesomeDude
It doesn't necessarily take maturity. One can be _extremely_ self-deprecating
and refuse to find any good parts in their code.

------
aroman
Some excellent points here. The inflexibility of the auth page and the
anti-"magic" stuff really hit home.

~~~
airtonix
How is having magic behaviour good?

~~~
mcintyre1994
It's not. S/he meant it's an excellent point that the magic behavior in Django
is 'ugly'.

------
moreentropy
Been there. Great talk. It wasn't whiny at all, more like this is stuff we
have to work on.

Mmm Belgian beer.

------
mixedbit
Why Django model is not an ORM?

~~~
k_bx
I'm not sure what Andrew meant, but as I understand django doesn't have
concept of ORM like, for example, SQLAlchemy.

What you can do in SqlAlchemy is, your business-objects could be not some
inheritances from some "Model" class, but rather just pure python objects. So
you'd implement your business-logic without any knowledge of database etc (ok,
you'd use some abstract interface for querying those objects). Then, you
describe your "models" as objects representing your database schema (and data
structures inside it). It's not the same as your business-objects and can
differ quite a bit. And at the end, you "map" one to another, so that ORM only
comes in when you map your business-objects into your models.

I'm still not sure why django models are not ORM, maybe because there's no
mapping (as I described) going on. Personally I'm fine with ORM termin for
django models :)

------
targusman
This is why I prefer web2py. Unfortunately all jobs I can find are for Django.
:(

