[kyllo]

I've developed non-trivial applications with both Rails and Django and while I agree that Django is more explicit, its overuse of class inheritance made it difficult to figure out what was going on, and made reference tools like this necessary: https://ccbv.co.uk/

I know you don't have to use class-based views and can just use functions with mixins instead, and that's the approach I prefer when working with Django. But if everyone else uses CBVs I still need to understand them.

Rails controllers use inheritance too, but they mostly just inherit directly from ActionController::Base or from ApplicationController. It's not a deeply nested hierarchy.

[true_religion]

Hmmm

When it come to their database model I didn't find their use of class-based inheritance to be too crazy. There's some meta-data hacking going on in there; but it wasn't too difficult to figure it out if you wanted to extend the Django ORM to interface with other databases.

In my case, I made an interface to read from ElasticSearch and return Django objects, and store back to ElasticSearch using regular Django objects as well. Since I wasn't creating/restoring everything to ES, my library had to create a partial model that'd look up the rest of the information in Postgres if you touched a field that hadn't been stored in ElasticSearch.

On the view side though, its not too complex when it comes to request objects, response objects, templates and middleware. Injecting new template engines is fairly straight forward, and the request/response objects are just data objects.

However, CBVs are horrible. I never used them. I begun using Django before them, and when they were introduced I tried using it for a month then dropped it entirely. I can see how they can be useful for a CRUD app, or some kind of application where there's a lot of code-reuse going on between the functions related to a particular object, but that's never been the case for me.

I just use functions with decorators for permission & object instantiation from the URL.

Django actually hides all of its ugly internals in their form classes.

Hardly anyone talks about that because for 90% of the use cases it just works, but the moment you want your form widgets to do something complex, you have to write the forms yourself---in their entirety.

I hear that Django 1.9/1.10 is going to give us templates for forms and refactor that code into something sensible. Hopefully it'll be good; but if its a debacle like CBV, I'll just continue doing form templating by hand and using Form only for validation and sanitization.

[kyllo]

I agree with all of the above. Django's Model system is great, and function-based views work well too, but the class-based views and forms are misguided attempts to apply OOP principles where they aren't really needed. Inheritance is just not the right tool for the job, it creates more problems than it solves.

[true_religion]

I would have been satisfied if the forms use the django templating system, instead of trying to use string manipulation to create HTML somewhere in the bowls of a python file.

How great would this be?

name = BooleanField(template='switch_not_radio_boxes.html')

Your template file spits out HTML for flip switches instead of radio boxes (e.g. Https://proto.io/freebies/onoff/), and the template can add javascript/css to be bundled into a singular location with the rest of the Form fields static assets.

It'd be simple.

But nope, instead BooleanFields use a widget that creates HTML & sprinkles error messages upon it through some byzantine means.