To what framework is it worth to switch from django

Question

The last framework, which I used, was Django. I enjoy a lot of things in that, like:

• The project structure is simple - there are not too many directories and files
• The admin interface
• Great documentation
• XML export-import
• The concept of Form objects: after you define a form, you can display the form in 1 line, you can even make a form from a database row (from an orm definition). [added on 30/12/2009]
• i18n [added on 31/12/2009]

But there are some limitations:

• as of december 2009 no model validation
• the templating system is only good as far as you don't need custom template tags
  • the idea to separate the design from the logic seemed good, it is frustrating, that I cannot sum n numbers in the view [edited on 30/12/2009]
  • the template language is not designer friendly
  • the stack trace of an ex in a custom template tag is useless (if used with python 2.6). There is a patch for it, but it will go into django just in 1.2
• django's orm (to connect to legacy systems)
  • cannot handle blob fields
  • cannot handle multi-column pk fields

Is there another web framework which has the good points of django, and does not have the listed limitations? Or is it possible to solve some problems in django?

ps: I will update the list based on the answers. I am sure there are more aspects to discuss...

---

I am free to use a framework in any other language, as long as I can install the stuff on a linux server

---

Answer 1

Hi, try Ruby on Rails. Although sometimes you have to write some more lines of code, you can customize it easier.

And the limitations you mentioned don't exist in Rails.

I've been using it for years and was able to do anything I wanted.

Answer 2

Not trying to defend Django (that is not my job! :-)) just trying to give you some pointers on your list of limitations...

as of december 2009 no model validation

What exactly do you mean by this? Validation is available at the form level... And you can always override the save() method to implement whatever logic you desire and stop the save operation... Can you give an example of a scenario?

the templating system is only good as far as you don't need custom template tags the idea to separate the design from the logic seemed good, it is frustrating, that I cannot sum 2 numbers in the view

Add two numbers?

That said, you are not married to Django's templating system. You can use, for instance, Jinja2.

the template language is not designer friendly

Uhhh... Why? Most designers I worked with had no problem working with template languages way more complex than Django's... Could you give an example of what you see as unfriendly? Maybe there is a work-around.

the stack trace of an ex in a custom template tag is useless (if used with python 2.6). There is a patch for it, but it will go into django just in 1.2

I haven't experienced this stack trace issue you discuss. You can always install the patch until Django 1.2 is around though. So it seems you have a solution available.

django's orm (to connect to legacy systems) cannot handle blob fields

If you are dealing with the need to store files in the database, maybe you should look at the django-storages' DatabaseStorage.

cannot handle multi-column pk fields

This, alongside with multiple database support, are the areas of real need of improvement - I agree.

I suppose you could not use models (just straight SQL) for models that have the multi-column pk requirement (yes, it would kill the admin, but it is doable). Frankly - I don't have that problem in my models because I prefer surrogate primary keys - if a legacy model is on my way, I add a surrogate primary key to it - all the legacy code should continue to work and Django will be happy. But I do have complete control over the database tables, which might not be your case.

Multi-column primary keys are medium priority for the 1.2 release.

Multidb is high priority for 1.2 release.

The 1.2 release is expected by March 2010. Sure, the date is not written in stone.

Given my experience with other frameworks, I would rather work around my issues and stick to Django.

Answer 3

While you can to some extent swap out the bits of Django you don't like, other frameworks make it easier to do so than Django.

Assuming you want to stick with Python, the next best alternative would be Pylons. You have SQLAlchemy + Formencode for validation; Mako/Jinja/Genshi all offer a more flexible alternative to Django templates.

Another option is roll-your-own with an "anti-framework" or toolkit of libraries for WSGI handling, data mapping etc. My favourite bag of tricks is Werkzeug + SQLAlchemy + Jinja2 but really whatever fits your needs and programming style.

A word of caution is that Pylons and more DIY frameworks require a better understanding of Python than Django for even trivial projects. That's not a bad thing : however I would recommend Python newbies to get their feet wet with Django first, as it has better documentation and fewer rough edges than the other alternatives. Once you are more confident then do look around, because Django, as you have discovered, is not always the best tool for the job.

Answer 4

The reason I'm still using django, even though there's a huge number of other rough areas, is because of the most basic, core feature to the framework, the request/response dispatch system. The killer feature is the urlresolvers.reverse() function. This means that any time you need to compute a link, you can do so robustly, without concern that any change you make elsewhere in the framework won't break any computed links. Although there may be a comparable capability for frameworks in other languages, there sure doesn't seem to be anything quite as polished as django's dispatch system for python, and for the frameworks in other languages I've tried, It certainly seems to be the exception, rather than the rule. I will continue to use django for this alone, even when I'm using something else for ORM, Templates, Form processing, serialization, scaffolding or just about any other feature.