Blog of Jeff A blog about programming and random other things.

9Feb/10link

Django’s Flaws

This is a response to Brandon Taylor. It was a bit lengthy, so I thought a post would be better off.

Like you, I felt this "poor" design pain from Rails. The less then spectacular docs (although that's changing too) made me prefer Django over it.
With that being said, the settings.py of Django is a crutch. There's quite a bit of needless configuration: You need to set template directories, installed apps, etc. While that's less than Java, why can't there be some reasonable defaults? Make template point to a local 'templates' subdirectory; default directory for media files; default to sqlite3 database config; time-zone defaulting to your computer's time settings; etc.
No migrations. Sure there are third party, but an official version would be nice. Most projects would be greatly aided by such a feature.
Django's reverse URL lookup system (for templates) is a pain. Besides the fact that the {%url%} is usually long with all the parameters (imagine a date-based a blog post URL). get_absolute_url in models seem dirty and hackish, but it's a lot shorter. Rails' routes provides this style of url referencing (by model instance).
Why no JavaScript integration with Django? Sure you can say it provides free choice, but that's why Rails has an advantage: it's not using the best javascript framework, in my opinion, but something is better than nothing. It's far easier to write simple javascript code through Rails then it is in Django.
Tying along the JS issue, is the templating problem. How would one go around supporting themes? What about different templates based on the incoming client? This has to be manually handled by custom-view code. Rails supports this pretty simply.
Django's admin is particularly amazing; however, it's more towards data entry and site admin (hence the name) but not regular usage -- it's not designed for web apps which have users "managing" their own content: for that you want to create a polished experience for the end user. Validations for both frameworks are done through the model.
Recently, the admin interface has gotten a lot more extensible, but it's still designed for the site admin in mind. While Rails' scaffolding isn't great, it's closer toward user-generated content, you're improving the design on behalf of the end user going to see it. Writing basic HTML for this stuff is pretty repetitive if you ask me.
If you like the argument from more of a Djangoist, I'll refer you to one of the creator's of Django.
http://simonwillison.net/2009/May/19/djng/
I've shared many of his pain points.
But Django's documentation is second to none in comparison to any open source project. Django's querying system through models is also great in comparison to Rails -- something that Rails 3 is also going to deliver.

Like you, I felt this "poor" design pain from Rails. The less then spectacular docs (although that's changing too) made me prefer Django over it.

With that being said, the settings.py of Django is a crutch. There's quite a bit of needless configuration: You need to set template directories, installed apps, etc. While that's less than Java, why can't there be some reasonable defaults? Make template point to a local 'templates' subdirectory; default directory for media files; default to sqlite3 database config; time-zone defaulting to your computer's time settings; etc.

No migrations. Sure there are third party apps, but an official version would be nice. Most projects would be greatly aided by such a feature.

Django's reverse URL lookup system is a pain. Besides the fact that the {%url%} is usually long with all the parameters (imagine a date-based a blog post URL). get_absolute_url in models seem dirty and hackish, but it's a lot shorter. Rails' routes provides this style of url referencing (by model instance).

Why isn't there JavaScript integration with Django? Sure you can say it provides free choice, but that's why Rails has an advantage: it's not using the best javascript framework, in my opinion, but something is better than nothing. It's far easier to write simple javascript code through Rails then it is in Django.

Related to the JavaScript issue is the templating problem. A view function usually only directs to one template. How would one support themes? What about different templates based on the incoming client? This has to be manually handled by custom-view code. Rails' render_to dispatcher in the controller makes this a lot easier.

No doubt Django's admin is awesome; however, it's more towards data entry and site admin (hence the name) but not regular usage -- it's not designed for web apps which have users "managing" their own content: for that you want to create a polished experience for the end user. Validations for both frameworks are done through the model.

Recently, the admin interface has gotten a lot more extensible, but it's still designed for the site admin in mind. While Rails' scaffolding isn't great, it's closer toward user-generated content, you're improving the design on behalf of the end user going to see it. Writing HTML isn't fun -- for me at least.

If you like the argument from more of a Djangoist, I'll refer you to one of the creator's of Django.

http://simonwillison.net/2009/May/19/djng/

I've shared many of his pain points.

But Django's documentation is second to none in comparison to any open source project. Django's querying system through models is also great in comparison to Rails. Rails 3 intends to copy Django on that respect.

The merb probably slowed the progress of Rails in the recent years.

  • Share/Bookmark
Tagged as: , , 4 Comments
15May/09link

Disqus for Python

I'm working on my Django blog app (something Cal Henderson jokes about), but since I'm too lazy to write a decent commenting system, I've been building upon Disqus. I thought it would be nice to separate it from a Django Application, resulting in pydisqus.

This is licensed under the BSD License. As a warning, this hasn't been thoroughly tested yet. Although it’s been decently documented via comments.

Here’s an example (obviously the api keys are not real):

import pydisqus
response = pydisqus.get_forum_list(user_api_key='key')
print response.code # prints the disqus API response. 'ok' is a successful api call.
print response.message # prints the parsed json of all the forums.
# we happen to know that this returns a list of forum objects.
# which the response object parsed and placed into payload.

for forum in response.payload:
    key = pydisqus.get_forum_api_key(user_api_key='key', forum_id=forum)
    print forum.name, key
# identical to code above
for forum in response.message:
    key = pydisqus.get_forum_api_key(user_api_key='key', forum_id=forum['id'])
    print forum['name'], key

Download it here (I’ll submit it to pypi when I have some time to test it through my Django App).

I haven’t finished the Disqus App for Django, so that’s not available.

  • Share/Bookmark
6Apr/09link

Django Blog Tutoral Completed

If you follow the feed (and don't check the site). All the Django Blog Tutorials have been posted. You can go to Part 4 and download its entirety if you haven't been following it.

For those who may be wondering, I'm digressing from Django for the time being to writing an article on Javascript. Afterwards, I intend on resuming Django tutorials.

  • Share/Bookmark

Recent Posts

Topics

Archives

Following

Links