One of the questions asked at Snakes & Rubies was about what Django could learn from Rails (and vice versa). Once I finish wrestling Final Cut Pro to the ground you’ll be able to see how Adrian and David answered the question, but in the meantime it got me thinking about some cool features of Rails that are worth ripping off… er… being inspired by:
find_or_create convenience methods. Pretty simple, so expect to see a similar method in Django pretty soon.
The through option for many-to-many relationships. The only way to add attributes to ManyToMany relationships in Django is with an explicit middle table, but then you lose the join methods that you’re used to.
Integrated unit of your models. It’s nice that Rails creates the tests directory automatically when you start a project (David I think referred to this as encouraging developers to do the right thing) but in general I don’t like the way Rails shits all over your project directory. All those folders are confusing.
It seems that django-admin startapp should have a “simple” and a “complete” option so you could choose between the two.
Generic relationships (David called these “polymorphic”, but I’m not sure that’s the right term). You actually can already do this in Django by doing something like:
class TaggedObject(meta.Model): content_type = meta.ForeignKey(core.ContentType) object_id = meta.IntegerField() def get_content_object(self): return self.get_content_type().get_object_for_this_type(self.object_id)However, it could be simpler; I’d love to see:
class TaggedObject(meta.Model): content_object = meta.GenericForeignKey()or:
class TaggedObject(meta.Model): content_objects = meta.GenericManyToMany()It struck me while watching David speak that our python-level many-to-many API isn’t so hot. Right now, to add a M2M relationship you’ve got to do something like:
story = stories.get_object(...) story_categories = [c.id for c in story.get_category_list()] if new_category.id not in story_categories: story_categories.append(new_category.id) story.set_categories(story_categories)That’s lame. This should work:
story = stories.get_object(...) story.add_category(new_category) story.remove_category(category_to_remove)
Something akin to routes. I actually don’t like the implementation in Rails all that much, but get_absolute_url() breaks the entire idea of URL abstraction, so it needs to get fixed. Simon suggested that the urlconf could define both forward and reverse lookups (which is a cool idea) but I’ve been unable (so far) to figure out a good syntax for this.
Comments:
Amen and +1 to all the stuff you mentioned.
It is nice to see that we have informed opinions on other web frameworks and critical view of our stuff. Way to go to improve Django!
I am glad to see that get_absolute_url() problem is recognized by Adrian and you --- the Django keepers. Did you see a discussion in #672 (http://code.djangoproject.c... Anyway it should be addressed because of many reasons (abstraction, portability, configurability, and so on).
Yeah, I've looked over #672... as always, the hardest part of figuring out a fix is finding something that's clean and simple. Although the current behavior is broken, you can't beat it for simplicity...
We'll figure out something, I'm sure :)
I still despise GenericForeignKey as it is totally non-relational - you lose all integrity checking of the RDBMS and cascades don't work either. It ties the database to this random content_type_id thing which is a nightmare to interpret in any other framework.
The way to do this is with real subclassing and mixins. I would much rather we didn't rush to a hack on this. ( And anything including content_type_id in model tables is a horrible hack.) I will do this eventually, it will take longer though.
I like the idea of some analogue to Routes. In my current project I'm considering custom template tags for the job. That may be the wrong spot architecturally -- but on the other hand, with the current system (hard-coded URLs) that's where they already are.
Also, thanks as always for posting so candidly and being so open to ideas from "outside." It's an inspirational aspect of Django development.
Routes was the thing that most interested me from David's presentation (though the DSL/declarative approach to creating apps is very sexy). Django is very flexible with urls on the way in, but once you get into the code it's back to the old string-formatting tricks.
Maybe I don't grok the definition of routes, but aren't they used to over-ride the URLs created by the "active mapping" pattern (or whatever its called that dispatches URLs to controller actions via a conventional pattern)?
I don't really see how routes would benefit Django's concept of urlconfs.
I personally like the way Django does URLs. It's flexible and I don't have to over-ride conventions. The declarative style it uses means I don't have to fight with someone else's idea of how I should construct my URLs.
So how exactly would routes change how Django does URLs?
I you already had No. 2 I would have convinced my boss to move to django a long time ago :/. What happened?
Leave a comment: