Inspired by the question series 'Hidden features of ...', I am curious to hear about your favorite Django tips or lesser known but useful features you know of.
I'm just going to start with a tip from myself :)
Use os.path.dirname() in settings.py to avoid hardcoded dirnames.
Don't hardcode path's in your settings.py if you want to run your project in different locations. Use the following code in settings.py if your templates and static files are located within the Django project directory:
# settings.py import os PROJECT_DIR = os.path.dirname(__file__) ... STATIC_DOC_ROOT = os.path.join(PROJECT_DIR, "static") ... TEMPLATE_DIRS = ( os.path.join(PROJECT_DIR, "templates"), )
Credits: I got this tip from the screencast 'Django From the Ground Up'.
This post is from the early days of Stack Overflow, and while we recognize its historical significance, we also recognize that the current community of users will likely close similar posts. Please feel free to read and learn from this post, but refrain from creating similar posts just because this one exists.
I'm interested in learning a web framework. The two big ones, as I gather, are Rails and Django. Which one is better and/or faster? Is one better designed or more logically consistent than the other? Is there another framework I should look into? How easy is it to set up and administer a Rails or Django server, and how easy is it to find a shared hosting plan?
To give a little background, the websites I'm currently used to making are in straight PHP (no framework) and I'd like to be able to manage some of the complexity that comes from feature creep. Outputting HTML with echo becomes a lot less fun the more you have to customize it. In addition, I don't know either Ruby or Python so I'm free to go either way.
note: I'm not interested in ASP. I'd like to develop on a Mac and deploy to Linux/FreeBSD and I don't think that ASP fits the bill.
To everyone that's replied so far: thank you! Choosing a web framework can be a difficult thing, so I'll try to narrow down what I would like to do.
First, I would like to build small, custom sites (hard to call them "apps") that serve data from a database, and optionally an administrative interface to manage everything behind the scenes. As an example, I have a website for my grandmother to showcase her artwork built in PHP. I've spent more time on the backend than the front end to enable her to reorder, relabel, and reprice her artwork as well as upload an image, tag it, and have it scaled and appear on her site.
I notice both frameworks generate "scaffolding" that can be used as a rudimentary admin interface; how would they handle non-textual data (like images)?
Also, when watching a Rails screencast, there was a casual mention that the framework does some singular/plural translation. This strikes me as quite odd - is this what is referred to as "magic" in Rails? If so, does Django (or any other framework) have a more sensible naming strategy?
From my experiences, rails seemed to be more of a black box than django. You issue some command and some stuff happened and you got a basic CRUD application. You run this particular function and something happened and you got something else as an output, not knowing what the middle bits were. While this is fine for easy things, the lack of online documentation (in my experience) was a huge hindrance.
Django, on the other hand, seems to be more logical and transparent about what's going on behind the scenes. There's no "magic". Django is also one of the best documented open source projects out there.
Just came back and saw your additions:
If you want something with an extensible admin, pick Django. This is a test in which Django shines. Its clean looking and is extensible. In my experience, the Rails scaffolding is typically thrown away as you add more functionality. Its meant to get you up and going, but not necessarily something you'll see in production. That being said, lists for grandma aren't exactly production :) Reordering field and such is fairly easy, especially given the many community contributions to the admin.
When people talk about "magic" in Rails (or any other framework for that matter), they're really talking about things happening without it being immediately obvious why or how. A key example of this is Rails' find_by_* function. Its autocompleted function that you don't explicitly define, but its just "magically" there. You can find a lot more information at http://www.stephenbartholomew.co.uk/2007/6/4/is-rails-magic Purely antecdotal, but I've found that Python (and Django) itself is much more explicit where as Ruby (and Rails) rely a lot more on convention ("That's just the way its done.")
I'm building a web application with Django. The reasons I chose Django were:
Now that I'm getting closer to thinking about publishing my work, I start being concerned about scale. The only information I found about the scaling capabilities of Django is provided by the Django team (I'm not saying anything to disregard them, but this is clearly not objective information...).
My questions to you:
"What are the largest sites built on Django today?"
There isn't any single place that collects information about traffic on Django built sites, so I'll have to take a stab at it using data from various locations. First, we have a list of Django sites on the front page of the main Django project page and then a list of Django built sites at djangosites.org. Going through the lists and picking some that I know have decent traffic we see:
pownce.com (no longer active): alexa rank about 65k. Mike Malone of Pownce, in his EuroDjangoCon presentation on Scaling Django Web Apps says "hundreds of hits per second". This is a very good presentation on how to scale Django, and makes some good points including (current) shortcomings in Django scalability.
"Can Django deal with 100,000 users daily, each visiting the site for a couple of hours?"
Yes, see above.
"Could a site like Stack Overflow run on Django?"
My gut feeling is yes but, as others answered and Mike Malone mentions in his presentation, database design is critical. Strong proof might also be found at www.cnprog.com if we can find any reliable traffic stats. Anyway, it's not just something that will happen by throwing together a bunch of Django models :)
There are, of course, many more sites and bloggers of interest, but I have got to stop somewhere!
Blog post about Using Django to build high-traffic site michaelmoore.com described as a top 10,000 website. Quantcast stats and compete.com stats.
I'm begining a new webapp in Python. I've narrowed my choices down to Django and Pylons. What are the pros/cons of each?
Disclaimer: I created Pylons.
It really depends on the type of application you're building. Both frameworks were originally made to solve different problems. Despite how far they've both come since their creation its still very useful to keep in mind the problems they were created to solve because many of those choices have guided further development.
Django was made for newspaper sites, not just a single newspaper (publishing) site, but for making entire sites quickly. They generally had a staff that needed to start pushing content into the system ASAP, even before the public version of the site might be done. This is still clearly reflected in Django as it has a very complete user-friendly admin interface for the staff to begin entering content.
At the time Django was made, SQLAlchemy wasn't around, and SQLObject was kind of... lacking, so Django has its own ORM. It's still lacking in many ways compared to SQLAlchemy, but it'll work just great for alot of people's needs.
Django also has the concept of 'apps', which are just directories inside a Django project that do a specific function for the site. This reflects the original creators needs to quickly share components of a site with other sites they made. For example, quickly adding comments, or reviews, to another Django site.
While you can use SQLAlchemy, or other template languages such as Mako, in Django, many of Django's strengths (the existing 'apps' you can re-use, the admin interface, parts of the form library) go up in smoke as soon as you use SQLAlchemy instead of Django's ORM.
Just like the Django authors made Django to scratch their particular itch, I made Pylons to scratch mine.
In my experience, creating sites is a very small portion of their life-span. I actually spend significantly more time maintaining a web application, or adding features to an existing one. So the first thing I wanted in the framework was common places to put the 'basics' of a web application, so that it'd be easier to maintain, and that if other people knew Pylons they'd have an easier time jumping in to help maintain a Pylons app.
For all the sites I've built, they generally involve very different database schemas and data back-ends, with little in common. So sharing 'apps' like Django does just isn't a priority, nor is it feasible given how different each app will actually be (you can't share parts requiring a specific concept of how users are handled if different apps need to handle them differently).
I also needed something small, that wasn't trying to run the show for me. I want to be able to go in and determine how something is going to respond without hoping the framework 'lets' me do it. For this reason, a Pylons app is a bit different from most frameworks, in that the project itself builds the application object, making it easy to get in and tweak and change any core bit as needed.
So the question someone trying to choose should be asking themselves, is what are they trying to build? Because that's really the best way to determine the appropriate framework to use for the task.
Also, at the moment, the Pylons Book is 100% up to date with Pylons, while Django's book has been updated for version 1.1 of Django.
There are at least half a dozen Django apps that provide OpenID authentication for Django:
I played around with a couple of them. Simon Willison's django-openid made a good impression, but as he is at the forefront of trendsetting in Djangoland, I sometimes have difficulties wrapping my head around his trends (e.g. the whole dynamic urlpatterns system in django-openid). What's more, I couldn't get login to work with Google.
django-authopenid made a good impression, and it seems to have good integration with django-registration. django-socialauth and django-socialregistration have support for Twitter and Facebook, which is definitely a plus. Who knows if and when Facebook will start to be an OpenID provider...? socialauth seems to have its share of problems, though.
So, what is the best OpenID app out there? Please share any positive (and negative) experience. Thanks!
The one that has proven to work best for me, and which seems most up-to-date is the one over at launchpad.
It integrated seamlessly with my application that already utilizes the django.auth module.
To get a copy run:
bzr branch lp:django-openid-auth
Or install it via PyPI
pip install django-openid-auth
I have done a little django development but it has all been in a text editor. I was curious what more advanced development tools others are using in their django development. I am used to using Visual Studio for development and really like the intellisense, code completion, and file organization it provides and would like to find something (or a combination of tools) that would provide some of this in the django/python environment.
I use Eclipse and a plain vanilla PyDev http://pydev.org/. There isn't any specific Django functionality. The best I came up with was setting up a run profile to run the development web server. If you add the web tools project (WTP), you'll get syntax highlighting in your templates but nothing that relates to the specific template language. Pydev is a decent plugin and if you are already familiar with Eclipse and use it for other projects it is a good way to go. I recall Netbeans starting to get Python support but I have no idea where that is right now. Lots of people rave about Netbeans 6 but in the Java world Eclipse still reigns as the king of the OSS IDEs.