Trying out Django

You might also want to check out Nitro, another Ruby-based web programming framework. Nitro differs from Rails in that Nitro does all the SQL setup for you.

http://www.nitrohq.com/diff?oid=493

Phil- I'm not sure I understand your comment. My issue with Django isn't about the database (though I do think it's interesting that Rails creates your model objects on the fly from the db, see my post about the OSCON Rails Session for more info), it's about Django storing view information in the model. Does nitro do something similar? That doesn't feel right to me.

Oh, I guess I do have one more issue with the db, why don't they ship with a pure python db like Gadfy, so that out of the box you have the complete stack and are ready to begin development?

You could consider the admin stuff in the model Django's version of "scaffolding"... It's only there to bootstrap the app building process-- just like Rails' scaffolding.

Just like the case with Rails' scaffolding... if you don't go past the tutorials in Django, you might be left with a wrong impression of the framework.

If/when you build your "real" application... things will be cleanly separated correctly... Although admin stuff stays in Model, Model will hold state stuff, Django "Views" act as controllers for grabbing Models and rendering output, and Django Templates are the final UI output. You'd control field ordering in your Templates. I dubbed this an "MTV" framework.

Read this thread for some more background on the MVC vs MTV idea... http://groups-beta.google.com/group/django-developers/browse_thread/thread/ 9b7084949f6e4e31?tvc=2

One could argue that Rails gets the "MVC" name wrong.

-Jason

Jason- What do you mean by going past the tutorials? The tutorials aren't good, or that there are hidden features? ;) (I suppose once one builds a "real" app, they will understand the framework more). I'll check out the thread you suggested.

thanks

If you only finish tutorials 1 and 2, where the admin interface is discussed and where you make interface changes in the model definition, you may be left an odd impression of the framework. And that odd impression is "you regularly put all your UI stuff in your model", when in reality, it only holds kinda-true for the admin UI... But even then, if you dig deeper into what powers the admin UI, you'll find that there are delivered views and templates that pick up the "hints" defined in the model for rendering output or changing state. I'll leave it to the Django authors to explain why they didn't completely remove the admin stuff from the Django Models. My guess is that they thought it was a pragmatic compromise betwee speed of development and strict adherence to MVC.

If you finish the remaining tutorials and build an application with the full stack (models, views, and templates)... you'll see your model isn't overloaded with UI stuff... With the example posted above (the wx app), your app would use Django's Models, Views, and Templates as you'd imagine... and if you wanted to, you can completely leave out the admin declaration from the model definition.

Regarding gadfly support and why they didn't provide it... well, it was originally developed with postgresql and that's what they use in production. When they open sourced Django last month, one of the goals was that a user community would add support for other databases. Within a week of Django's unveiling, MySQL and SQLLite support was added. I'm currently working on Oracle support (http://code.djangoproject.com/ticket/87).

SQLLite support probably fits where gadfly would right now-- a fast way to get started with development without any setup/install pain. If someone had the time/motivation to add gadfly support, then I'm sure the Django devs would be happy to accept the contribution. :-)

By the way, love the blog. Thanks for all the posts from OSCON. :-)

Mat: My suggestion of Nitro was because Django claims to do all of your SQL setup (no need to write SQL), while Rails (currently) requires you to do some SQL setup. This aspect of Rails seems to violate the DRY principle in my thinking: why do I need to define my database in two places (once in a Ruby class and again in SQL)? Nitro, like Django, claims that you need not write any SQL - for me this seems like a big plus as I would rather not be bothered with SQL. (OK, I'll admit, I'm one of those people who says "hey, my language has hashes, classes even Struct's, why do I need a database?")

Jason- Thanks, I'm glad enjoy my blog. I'm planning to finish the rest of the tutorials (it's a matter of time...).

There is always a fine line to walk between adherence to "standards" (like mvc) and making something useable. Just from the 3 hour demo of Rails by David, I was very impressed by what they've done, and it looks like they have a pretty good balance. (I prefer python though ;))

BTW, It's awesome that people like you are creating a community around Django. Good job.

PHL - As I noted in my post on the OSCON Rails session, the actual state of the model classes is NOT in the ruby code, it's in the db and programmatically added to your ruby instances on the fly. I specifically asked David why he did this and he said "once you do anything non trivial with sql generation, things break". Well the jury is still out on that (is hibernate causing lots of people grief?), but I thought it was cool how he could update the db on the fly and everything else still worked (without touching the code). (Plus it seems to violate a DRY and DB principle of not storing anything more than once. Now if you change the model state in the code and don't regenerate the db schema things are going to break). I'd love to hear from people with more ORM experience than me (practically none) chime in on this.

I can't wait for a solid python alternative to the JSP/Servlet/Struts toolset, but until there's something that supports internationalization as well as the Java world does, I can't really use python for web work, which is frustrating.

• It appears someone in the Django world is thinking about this, but it's a lot of work to backfit a toolkit that didn't have i18n designed in from the beginning -- and this doesn't even take the existing site.py/setdefaultencoding mess into consideration. I love python and use it for everything *except* web work, but I hate how nasty it can be to work with unicode, and I've noticed how that affects a lot of projects like Django.