1š
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.
14š
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
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.
- [Django]-Switch to Django Custom User Model, Groups and Permissions
- [Django]-Do websockets send and receive full messages?
- [Django]-DRF: Always apply default permission class
- [Django]-Crispy-forms InlineRadios don't show my model state
- [Django]-Django urlpatterns translated with ugettext lazy ā if 404 how to check again if url matches for another language?
5š
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.
- [Django]-Show models.ManyToManyField as inline, with the same form as models.ForeignKey inline
- [Django]-How to filter generic foreign keys?
- [Django]-Django admin ā Wrong model object at edit page
3š
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.