Among my personal friends, I don’t think it’s any secret that Django is currently my favorite web framework.  In particular, Django has what I believe to be the very most important element that a MVC framework can have – a solid, consistent philosophy that developers can adopt, meditate on, and integrate into their thinking as they proceed through any project.

One of the tenets of Django (albeit not a “top-level” holding like DRY, OaoO, minimal code, explicit over implicit, etc.) is that Django declines to use “Magic” unless it is overwhelmingly easier than the mundane solution that it replaces.  Django also veers toward the agnostic – meaning that one can use any naming paradigm, template strategy, URL convention, etc.

Exactly what techniques constitute “Magic” may be in the eye of the beholder, but generally we think of magic encompassing those techniques that are not part of a programming paradigm, but that work anyway “just because.”  Gnosticism, on the other hand, is pretty obvious when it rears itself: If you MUST use jQuery or you MUST name every variable drupal.something, you know that you are not working with an agnostic framework.

The SlashRoot team is currently working on a great project for Carbon Ads – a project that aims to enable small publishers to collectively sell ad space to pre-vetted, exclusive, and otherwise unattainable advertisers.  Think Adsense meets your favorite organic co-op.

Among the interesting elements to tackle in Django, as is often challenging in MVC frameworks, in the question of how to model different types of users.

The lazy (inorganic) way, of course, is to simply apply a “type” attribute to the user model and then ForeignKey each individual user class.  However, this leaves tremendous room for error.  For example (and this example in fact has come up in this project) – what if the developer creating the “admin” model has a different idea of how to track names than the developer creating the “publisher” model – may one of them thinks that the full name belongs in a single field while the other separates first and last names.  This is a major problem for any page that lists all users by real name.

To me, the most organic solution is to separate elements into two categories: Those that two or more classes of people have vs. those that only one class of people has.  That way, the attributes in the former category can be assigned to a parent class (perhaps as an optional field) while the latter can belong exclusively in a child class, on a separate database table to enhance performance.

So, how does Django treat this contingency?  With magic, I’m afraid.

The Django documentation on this point suggests using the “lower case” name of the class in question, which has two deviations from the general Django philosophy:

1) It is gnostic, plain and simple.  It assumes that you have adopted upper-case or CamelCase naming conventions for your models, and that you can use lowercase as an alternative.

2) It seems to me to be magic.  There is no *reason* why the lower-case class name should refer to the logical question of whether or not an object is in a child class of a parent model.  It just…. works.

Mind you, I can deal with both these issues.  I think that the “magic” issue is of more concern to the programming purist, because it can be genuinely confusing.  Case in point, I actually had to wonder how to access the “not magic” of this solution – although “if not someobject.somelowercaseclass” does in fact return TRUE for objects outside the child class in question, it took me some time to wrap my head around this, simply because “someobject.somelowercaseclass” is not instinctively a logical value to me – the “magic” distracted my view for a moment.

Thus, I had this interesting (and perhaps telling, I think) exchange in #django:

<jMyles> Philosophical question:  Does the ability to ask for a child class with lower-case lettering represent “magic”?  (see: http://docs.djangoproject.com/en/dev/topics/db/models/#id7)

<jMyles> To rephrase my question: Is the use of a lowercase letter to inquire about a child-class part of an established programming technique?  Or is it a (rare) example of magic in Django?

<igloo_x> jMyles> what do you mean “child class”

<jMyles> igloo_x: Actually I mean child model

<jMyles> igloo_x: Like “Restaurant” becomes “restaurant” in the test in this example: http://docs.djangoproject.com/en/dev/topics/db/models/#id7

<jMyles> igloo_x: Also, in that example, how can I ask if the object is NOT in the child class “restaurant”?

<jMyles> igloo_x: I’m looking at the third code block down from that link – “If you have a Place  that is also a Restaurant, you can get from the Place object to the Restaurant  object by using the lower-case version of the model name:”

<igloo_x> it’s magic, as far as I know. you can override it though. I think the argument is ‘related_name’ or something

<jMyles> igloo_x: OK, that’s what I thought.    And then, how can I ask if an object is NOT in that class?

<jMyles> igloo_x: ie, “if p.restaurant:” works fine, but how can I ask if it is not in that child class?

<igloo_x> i’m not sure about that, I’ve never messed with model inheritance before

<igloo_x> does “if not p.restaurant:” work though?

<jMyles> igloo_x: wow.  yes it does – mad overthinking on my part.

<igloo_x> good old python!

Be Sociable, Share!

•