Django's Architecture: The Good, The Bad, and The Ugly

https://speakerdeck.com/andrewgodwin/djangos-architecture-the-good-the-bad-and-the-ugly

by rubygnome • 13 years ago

76 41 13 years ago

speakerdeck.com

aroman• 13 years ago

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

airtonix3• 13 years ago

How is having magic behaviour good?

mcintyre1994• 13 years ago

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

gojomo• 13 years ago

[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...

thejosh• 13 years ago

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.

makeramen• 13 years ago

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/

[2] https://docs.djangoproject.com/en/1.5/topics/auth/customizin...

k_bx4• 13 years ago

Well, considering that Andrew is an author of South, maybe he just wanted to point out that it's something that should be part of django (simple "add a field" operations).

mixmastamyk3• 13 years ago

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?

amarsahinovic• 13 years ago

https://github.com/twoscoops/django-admin2/

airtonix3• 13 years ago

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

obviouslygreen2• 13 years ago

I'd say the admin app already looks a bit like Bootstrap, and it's hard to claim either in its default form is more or less "homely" than the other. Granted, I like both.

Also, the admin app isn't supposed to be client-facing; it's a very effective but not-extremely-user-friendly way to view data without having to resort to SSH'ing in and running ORM queries on Django's CLI (or, worse, the database's CLI).

You can use it that way (and many of us have; I'm not innocent), but encouraging that with a pretty application of Bootstrap will likely give a lot of new developers the wrong idea on the tool's purpose.

ubernostrum• 13 years ago

What's happening is that low-level APIs for manipulating the database schema are being worked on, and will become part of Django. Then, many types of tools -- including migration tools -- will be able to be built on top of those APIs.

In the meantime, South still works quite well.

Flip-per• 13 years ago

I agree. Almost every point is fixed/improved by now - if that is why this link was posted it should be pointed out.

mixedbit• 13 years ago

Why Django model is not an ORM?

k_bx4• 13 years ago

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 :)

kingkilr• 13 years ago

The models system absolutely provides an ORM, what Andrew was (I assume) saying was that the models layer encompasses more (and less) than what some people mean when they say ORM. For example the models layer includes validation, and all sorts of other pieces of metadata, not just the mapping; and it doesn't include some of the things other people think ORMs mean like SQLAlchemy or Hibernate's concept of a session.

k_bx4• 13 years ago

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).

airtonix3• 13 years ago

Perhaps you're the only one? I have no problems reading and working out what's going on (I'm not even what you would call a great programmer)

obviouslygreen2• 13 years ago

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_bx4• 13 years ago

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.

jgj• 13 years ago

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

Udo• 13 years ago

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.

targusman• 13 years ago

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

mattchew2• 13 years ago

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.

eli• 13 years ago

If it makes you feel better, you're not the only one.

sashahart• 13 years ago

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

lojack• 13 years ago

Not 100% sure this is what mattchew was talking about, but instead of defining the form and then rendering the form field by doing something like this:

{{ form.thefield }}

You would instead simply define the model and render the form field with something like this:

{{ model.thefield | render_input }}

Or, if you had a regular Form (i.e. not a ModelForm) you would do something like this:

{{ render_input:name="field_name" }}

And if you wanted validation or something, you'd need to create your own render_* methods to perform that validation.

mattchew2• 13 years ago

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://guides.rubyonrails.org/form_helpers.html

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

RussianCow• 13 years ago

Really? I find that to be one of Django's biggest wins for me. The only thing I dislike about it is that you need to use multiple forms if you need to wrap multiple models. But having forms that aren't tied to a model is so easy in Django.

huxley• 13 years ago

For a big subset of stuff, the Django forms are perfectly fine once you grok what they do, but in recent years, I've usually supplemented them with CrispyForms [1] (used to django-uni-form) and FloppyForms [2] --either individually or in combo-- for extra form flexibility.

[1] https://github.com/maraujop/django-crispy-forms

[2] https://github.com/brutasse/django-floppyforms

anderspetersson• 13 years ago

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

brokentone• 13 years ago

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• 13 years ago

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

moreentropy• 13 years ago

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

Mmm Belgian beer.

csense• 13 years ago

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.

Django's Architecture: The Good, The Bad, and The Ugly

Related Stories