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:
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).
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
41 comments
[ 3.6 ms ] story [ 66.1 ms ] threadThe 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...
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.
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...
Also, how about defaulting to bootstrap for the homely-looking admin app?
It seems to me that it does what it set out to do. Well.
If you want bootstrap BTW, this is a dropin addon https://github.com/riccardo-forina/django-admin-bootstrapped
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.
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.
In the meantime, South still works quite well.
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 :)
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.
> {{ 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.
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...
[1] https://github.com/maraujop/django-crispy-forms
[2] https://github.com/brutasse/django-floppyforms
Mmm Belgian beer.