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

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?

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.

I think keeping it ugly does Django a disservice. People associate the hideous yellow on cyan header with it and might think ... oh that rails/node stuff looks more professional (less like it was created by 90's-IT-guy). No matter that the issues are orthogonal, people aren't aware of the nuances.

The widgets are fine-looking, though increasingly dated. Why not outsource this work to someone who cares about it? Its community must dwarf Django's.

There's some truth to your statement about encouragement, but it reminds me of the phrase, don't "cut off your nose to spite your face." Plus, it isn't the author's place to dictate how the user will use it.

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.

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

The only problems I've had with the admin is that it's very model based, while my user actions don't neccesarily reflect specific models.

If you want bootstrap BTW, this is a dropin addon https://github.com/riccardo-forina/django-admin-bootstrapped

Bootstrap is ideal for internal admin interfaces

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

We don't have to solve every problem simultaneously.

Could you elaborate about what is horrible with Bootstrap?

It seems to me that it does what it set out to do. Well.

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

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

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

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.

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.

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

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

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

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.

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.

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

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 is a much better web framework now than it was 2 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...

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.

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

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.

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.

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)

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.

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

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

How is having magic behaviour good?

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

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

Mmm Belgian beer.

Why Django model is not an ORM?

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

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.