I just finished listening to the Adrian Holovaty interview that I just recently blogged. I’ll post later today with a review of it, but, basically, it’s an excellent interview. Good questions, great answers.
Something that Adrian had mentioned in the interview (can’t remember what it was now) made me think about Django as compared to other Python web frameworks. Django is a unified framework. It has an ORM, a templating system, a URL mapper, and other miscelania. It is built together to solve the problem of building websites and web applications. Every piece of Django is built with the big picture in mind. Every piece of Django is also built with the goal of total integration in mind. While the components that make up Django can be used outside of Django, their re-use outside of Django was not a primary consideration in their design and development. Usage within Django was the primary concern.
This unification of components is one of Django’s key strengths. It allows the development of Django to get the big picture. It provides a framework where the components “just work” together. It provides a framework with strong accountability; if someone in the Django dev team breaks a component’s interaction with another component, they are accountable to the project they are working on to fix it. If you use various components from various sources and one of the components break another component, the accountability isn’t as strong. Yes, there is accountability to the community, but that isn’t as strong as the accountability to one’s own developement team.
Note that I have chosen to post this entry under an “Opinion” category. I believe that Django’s philosophy of owning the whole framework is the best way to go. Others, most notably TurboGears, believe differently. I’m not going to knock TurboGears (or anyone else who has taken on the brobdingnagian task of creating an open source web framework). I think Kevin has done a great job with TurboGears and I’m excited about the ideas that invariably cross-pollinate from projects like this. I’m just saying that if I were going to build my own web framework, I would choose the Django route. I would build it from scratch because of the particular set of benefits that come from that course of action.
This will likely spur another discussion of re-use vs. reinventing the wheel. I’m not going to discount all code re-use. I think it has its place. I also think that there are times when the benefits of non-re-use outweigh re-use. And I think Django is a perfect case-study arount that assertion.
good
Jeremy:
1) Do you know about some web site where I can see a complete and middle-complex development case of a Django application, that goes according to Django philosophy and Django "best practices" (does it have?), and that shows all its components working together? I would like to see the python code of that development. Actually I observe some very simple isolated examples in the Django web site but I can not see the big picture of a complete application developed under Django.
2) Did you find some component in Django that let us search documents in a Web Site?
and
3) I read many comments that indicate Django is excellent for Web Content Management applications (newspapers, for example) but for commercial applications that requires many transactions, use of datagrids, intelligent and complex validations, AJAX, locking with databases, logging, etc. we must work very hard.
What do you think.
Thanks!!
Vizcayno,
1) You might want to just thumb through http://code.djangoproject.com/wiki/DjangoPoweredSites I'm not sure how many of these are open source, so it may not help you. You also may want to check out http://code.djangoproject.com/ and look at the section entitled "Example applications". I'm not aware of an end-to-end tutorial which uses the construction of a web application as its premise...although that idea has much promise.
2) I'm not aware of anything like this. I would almost think that you would need to create a custom application that knows what tables and columns to search through and what type of URL to give when it comes back.
3) I think that this type of categorization for Django, though, of being great for CMS, but not so good for "real" web applications (and I've heard this quite a bit) is unfortunate. The truth is that Django was initially created for a more CMSish type of application, i.e. the newspaper industry. I don't think that it's necessarily any worse for non-CMSish web applications that, say, Rails would be good for. It is broken up into a very cleanly separated MVC (they call it TMV) paradigm. The ORM is really great. I don't see it being any more restrictive than SQLObject. The templating system is great in its own simplistic way, IMHO. And the and the "controller" (they call it the "view") dispatches user requests appropriately. I don't see any of this being particularly limiting. Django is currently in the process of integrating a bit with the Dojo Javascript library, so hopefully, you'll get some Ajaxy goodness soon. But I would contest that doing some of the things that you mention (transactions, datagrids, AJAX, DB locking, etc) are just hard anyway regardless of the framework. Anyway, that's my take on it.
Thanks for the well-thought-out question!