7 ms·
Django's Architecture: The Good, The Bad, and The Ugly
- aroman 13y agoSome excellent points here. The inflexibility of the auth page and the anti-"magic" stuff really hit home.
- airtonix 13y agoHow is having magic behaviour good?
- mcintyre1994 13y agoIt's not. S/he meant it's an excellent point that the magic behavior in Django is 'ugly'.
- gojomo 13y 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-migrations-for-django http://www.kickstarter.com/projects/andrewgodwin/schema-migr...
- thejosh 13y agoAlmost 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 13y agoSomeone 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/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/1.5/topics/auth/customizin...
- k_bx 13y agoWell, 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).
- mixmastamyk 13y agoDidn'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 13y agohttps://github.com/twoscoops/django-admin2/ https://github.com/twoscoops/django-admin2/
- airtonix 13y agobootstrap is horrible and your suggestion doesn't address the problem.
- berntb 13y agoCould you elaborate about what is horrible with Bootstrap? It seems to me that it does what it set out to do. Well.
- joelhaasnoot 13y agoThe 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 https://github.com/riccardo-forina/django-admin-bootstrapped
- manojlds 13y agoBootstrap is ideal for internal admin interfaces
- 13y ago
- mixedbit 13y agoWhy Django model is not an ORM?
- k_bx 13y agoI'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 13y agoThe 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_bx 13y agoFor 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).
- airtonix 13y agoPerhaps 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)
- obviouslygreen 13y agoNot 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 13y agoI 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 13y agoHere'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 13y agoThank 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 13y agoThis is why I prefer web2py. Unfortunately all jobs I can find are for Django. :(
- mattchew 13y agoI 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 13y agoIf it makes you feel better, you're not the only one.
- sashahart 13y agoI'm curious about 'field helpers,' can you point to a page or briefly describe the difference?
- lojack 13y agoNot 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.
- mattchew 13y agoSure, 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_helper.html http://ellislab.com/codeigniter/user-guide/helpers/form_help... 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).aspx http://msdn.microsoft.com/en-us/library/dd410596(v=vs.100).a...
- 13y ago
- anderspetersson 13y agoDjango is a much better web framework now than it was 2 years ago.
- brokentone 13y agoShows 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 13y agoIt doesn't necessarily take maturity. One can be extremely self-deprecating and refuse to find any good parts in their code.
- moreentropy 13y agoBeen there. Great talk. It wasn't whiny at all, more like this is stuff we have to work on. Mmm Belgian beer.
- csense 13y agoThose 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.