KuraFire Network

Latest addition: Jan 19, 2007: Times are changing

Log

Django: first impressions

· By Faruk Ateş on May 22, 2006 · 32 comments ·

Subject level: Intermediate

For a long time now I've been thinking about where to take my programming next: should I build yet another PHP-PostgreSQL Content Management System, one with real framework tendencies, or should I jump the bandwagon and learn Ruby on Rails? No decision was made when one day, Jeff Croft started talking about Django. He has since published a few pieces on it, but just the introduction was enough to sway me. I compared Ruby and Django for a bit, found that Python (Django's underlying language) is much more my thing than Ruby is, realized that Django's philosophies were much more akin to my own and felt that Ruby on Rails was too intently focused on hype, AJAX and Prototype (a JavaScript liberary I've only heard bad things about). So Django it is, and here I am now to give you my first impressions of it so far.

Before getting into it, I'll explain what Django is in a nutshell: Django is a web framework built to make developing websites and web apps much faster and more efficiently. The people behind Django are very big on the DRY-principle: Don't Repeat Yourself. As a result, making websites and expanding them with new features and options is easy as can be. For a more thorough explanation, I suggest reading the Django overview page.

If you look at my front page you'll see that I put up an "I wish this site were powered by Django"-badge, which is a good indication of how I feel about Django right now. I really wish I was already fluent in it and building sites with it left and right, it's that appealing to me. However, it will be good to know where I'm coming from before you get the wrong idea: I am a programmer by nature, and web design, accessibility and user interaction are just interests I'm hoping to learn more of. If you thought I was a designer who did perhaps a bit of JavaScript but no more programming than that, you'd get a really skewed idea of Django by reading the following post. I can't stress enough that I'm writing this from a die-hard programmer's perspective.

Having said that, I will now say this: Django is awesome. But let's start at the beginning.

Installation

Since Django is a framework, not quite entirely unlike your average Model-View-Controller framework, it requires a fairly complex installation. If you're only familiar with standard PHP-like programming, Django's setup will be complex and unintuitive to you. Rather than starting a script and saving it with the right extension on the location where you want to access it, Django requires you to set up a source directory where the actual Django libraries will reside, a projects directory where you build your Django-powered projects (apps / websites), and a web-accessible location where you only put a few files that will internally forward requests to the Django engine. Your Django-powered website will thus be made "behind the scenes" and exist on your server in a location you can't access through your web browser. This is an approach that is actually highly favorable because your actual scripts are much better protected from the dangerous web. PHP technically allows for this approach, but it's rarely used that way.

Installing Django is a tricky thing, though. You need to do a lot of server-side configurations by hand, most of which are beyond what an average web designer will be familiar with. It can also be a hit-or-miss process, depending on how nice your webhost is when it comes to Python. Some hosts (such as Dreamhost) have Python-caching in place which can really make matters frustrating if you're not aware of them. Fortunately, Jeff Croft posted an installation guide for using Django with Dreamhost. If you want to try out Django, I do suggest getting an account with Dreamhost because they also have a fantastic Wiki with lots of useful information on Django and a whole slew of other things, and they're dirt cheap while offering lots of space, bandwidth and features. But enough with the sales pitch...

After you get Django set up, it's highly advisable to start with the Django tutorials. Additionally, I personally recommend reading the Django documentation as well, or at least go through some of the less advanced parts of it, so that you get a good feel for Django.

Working with Django

Whilst I worked my way through the tutorials, Django's potential become more and more clear to me. To start out, you first need to create an "app" - basically a little module serving one specific purpose. In the tutorials, you will create a Poll app, which eventually becomes a plug-and-play poll system that you can add and include in any Django-powered site. Any app can be as simple or complex as you want it to be: think of an app that powers a blog system complete with comments, or just a comments app that you can use in combination with a blog-only app but also a photo gallery app and a calendar app. Once you get the hang of how the apps work and can work with each other as an integrated whole, you start seeing some major benefits of working this way.

One of the things that makes all this so nice is the simplicity and cleanliness of the code required to make these apps: you first create a Model, which is the database schema for your app. In your Model you define what kind of fields you want, such as a title and entry text for a blog app, or the name, email and website fields for a comment app. Your app Model is not limited to one database table; it can contain as many tables as you need because your one single app can be a very complex and powerful, multi-featured app (and it usually will be, too).

After you've put your Model together you need to synchronize it with the database. This is a small step but unfortunately it has to be done with a manual command, i.e. there is no simple "Synchronize Database" button or an automatic synching toggle. Next, it's time to configure the URL's that you want your app to use, and write the corresponding Views. The Views-part of Django is where your main processing takes place - that is, the bit of processing in what little you actually have to do. In a View, you specify what should happen in a certain situation, i.e. a poll choice is voted on so now we need to update the vote count for that choice.

The URL configuration and the Views work together very nicely, so that you can relegate basic actions (such as listing polls on the index page, listing one poll with options on detail pages, etc.) to the URL configuration and only put the real processing directives in the View. Django offers a lot of shortcuts for this so that you don't have to repeat your code for all the basic actions, leaving a very clean, lean Views file with only the absolutely minimum amount of code required.

Templates

Django comes with many useful things out of the box. One of these is their template engine, which is another reason why I have that badge on my front page. Django's template engine is easily the nicest I've ever seen, and I've seen and built many. You can use very powerful and useful conditions, loops and filters in your templates. Additionally, template inheritance makes life really easy when building websites that consist of more than one page.

In your Views and URL configurations, you specify which templates to use in what situations. Templates inherit the variables from that View so you can access your content directly and easily. Also, you can decouple each app and turn it into a "bundle" for distribution (whether you make it public or just re-use the app on other websites of your own is, of course, up to you). The templates can be bundled with it, which means you can make use of Django's plug-and-play architecture real easily: just put the app "bundle" in your project and you're good to go!

If you don't want to use Django's own template engine you don't have to, but with such a clean and powerful system I really see no reason at all not to take advantage of it. The same template system powers Django's built-in admin interface, so you can customize that in the same way if you want to. Speaking of which...

The admin interface

Django also comes with a built-in admin interface, one of its biggest selling points for me. Rather than having to build an admin interface yourself, a process that is ridiculously repetitive, frustrating, time-consuming and boring, Django offers you the ability to have the admin interface build itself, based on your Models. But don't worry: it's flexible enough to let you configure it to suit your needs entirely.

Jeff Croft has made a nice write-up of how the admin interface is made through just a few extra lines of code in your Model, but the second Django tutorial gives you an even more thorough introduction of just how much you can do with it and how incredibly flexible it is. Also, it's worth noting that Wilson Miner designed the admin interface, as it looks fantastic and is a bliss to use.

Conclusion

I haven't yet had the time to fiddle around with Django a lot beyond the tutorials, but I do know that I am looking forward to learning more about it and using it for all the websites I've got lined up. There are some things to keep in mind, though.

For one, Django is not a magic toolset. You still need to do actual programming in Python if you want to use it, even though it's relatively straightforward Python only. Creating the Models and Views is pretty simple, but it takes getting used to and making more complex and integrated apps with Django will still take quite some effort and, above all, practice.

If you're unfamiliar with Python, you will be quite overwhelmed when you get your first Python error. Where PHP spits out a relatively simple one-line error pointing to the line in the script where you did something wrong, Python will give you at least a page full of various notices, warnings and errors along with a lot of data that is extremely technical. More importantly, they don't make it very easy for you to spot what you did wrong, or where. If you're new to Python and Django, this can be a bit of a hurdle. If, however, you made a Django-error (as opposed to a Python syntax error), Django will give you a much nicer, cleaner and more descriptive error message that explains why you're getting this error page. It generally has enough information to tell you exactly what you need to know to fix it.

Jeff Croft talks about "Django for non-programmers" but the reason I'm so excited about Django is because I'm a programmer. I've built several Content Management Systems all by myself, I've worked on existing ones and expanded similar systems far beyond their intended scope, and the one complaint I have about programming, after all these years, is that it's so much hassle and work for so many simple little things. Django turns that around entirely: with very little work, you can get a lot accomplished. As a programmer, I'm excited because I know that I won't have to do any admin interface building anymore, and I won't have to worry about all the little details. Instead, I can focus on what I like most about programming: coming up with features for a website and implementing them. Django makes that process ridiculously easy and fast, in a very clean and pragmatic way. Altering entire systems can be as simple as changing or adding a few lines to the Model, synchronizing the database and you're done.

However, as a counter-statement Wilson Miner shows how a designer can use Django very easily by taking advantage of its built-in Generic Views. If you read his post, you'll see that there really is a lot of potential in Django for designers; it just takes a few bits of programming and you sacrifice some more advanced possibilities in return.

Before I get to my real conclusion, let's go over a list of all aspects:

Pros
  • Incredibly powerful
  • Built-in admin interface that looks and works great
  • Built-in template engine that is easy to use and still very powerful
  • Loose coupling of systems: apps can co-exist separately but also integrate with each other easily
  • Adding new features to websites has never been easier or cleaner
  • Very clean, pragmatic approach overall
  • No stuffing you with inaccessible AJAX-integration (like Ruby on Rails does)
  • Designer-friendly, to an extent
Cons
  • Technical hassle to install
  • Python errors can be overwhelming and confusing
  • Learning curve much harder for non-programmers to take real advantage of Django's potential
  • Non-designers do need to learn basic Python programming to use Django
  • Easy enough for non-designers to use

Now, if you read that last item on the Cons list, you'll wonder why I put it there and not with the Pros, because isn't that a good thing? Yes and no. For a designer, or basically just a non-programmer, being able to make use of Django is a good thing. The problem is, non-programmers are generally not familiar with good programming principles or good database design and normalization. As a designer, why would you need to know how to normalize a database, right? Well, if you use Django, you really should, or you may just end up writing poor, inefficient Models simply through not knowing any better. Django is a great system, but it's still a tool that can be used poorly.

Nevertheless, I heartily recommend Django to anyone who wants to give it a try, or anyone who is thinking about moving to a framework in general. If you aren't a programmer, it's a good idea to read up on good database design a bit, or ask help from a friend who's skilled in that area. If you are a programmer, Django offers you tremendous power and makes it extremely easy for you to utilize and harness this power to do many great things with minimal effort and in practically no time at all.

So who should really look into Django? It's hard to say: I see great uses for it in a small business, such as a two or three-person web design agency where one of them is a programmer, but as Django was developed by and for a very large business, its uses in that area are undeniable as well. In fact, I'm having a hard time coming up with any group that Django is truly unsuitable for. Of course, there are situations where it's not worth migrating an existing system to Django, such as larger sites that have long been optimized in their current architecture. For new projects, though, I think Django is a great solution, and I plan to get very fluent in it myself real soon. Also, I hope to write more about Django in the near future and put up some examples and tutorials.

Oh, and if you do sign up with Dreamhost to get started with Django, or if you already have an account there, please vote for adding PostgreSQL to Dreamhost as well. PostgreSQL offers a lot of benefits over MySQL (something I'll explain in more detail soon), but Dreamhost as of yet doesn't offer it. The more people vote for it, though, the more likely it is we'll see it being added soon! Thanks in advance.

Update: Phil Powell posted a Django: first impressions-post of his own. He focuses almost entirely on the technical side of Django, quite the opposite of what I did in my post (which was: trying not to get technical at all, if possible). It's well worth the read, because he makes some very useful observations if you're curious about Django on the more technical level.

Bookmark: Newsvine del.icio.us Digg

Comments

32 comments

#1 · Sjors · May 22, 2006 (15:26)

I told you that you would like Python. :p

#2 · Faruk Ateş · May 22, 2006 (15:32)

Did I ever deny it? Cos I don't think I ever disagreed on it; it may have taken me a while to get into it (i.e. Django) but other than that....

#3 · Adrian Holovaty · May 22, 2006 (16:42)

What a fantastic write-up! Thanks for all your nice words, and let us know if you have any ideas or suggestions for making Django better.

--Adrian (Django dev)

#4 · Sjors · May 22, 2006 (17:06)

I don't deny you not denying it. :S
A while back on IRC you mentioned the lack of strictness in PHP and how that sucked. I told you then that if you liked strictness you would love python. And now you do. :)

#5 · Jeff Croft · May 22, 2006 (17:10)

Nice work, Faruk.

I think you make a lot of good points about Django for programmers. My Django for Non-Programmers bit and Wilson's Build a Portfolio in 30 Minutes thing got a lot of attention and that's cool -- but it's important for people that understand that Django is for programmers first, and can really benefit a "real" programmer by taking a lot of the grunt work out of what they do.

So, while I still think that Django's combination of generic views, a built-in admin interface, and a kick-ass template language make it a great platform for designers who do just a bit of programming to get their feet wet, there's no question that it's really made for programmers and the "non-programmer" stuff Wilson and I have talked about publicly only scratches the surface of what someone who knows Python can do with it.

By the way, I agree that the install process can be a bit tricky, especially when doing it on FastCGI like the Dreamhost setup. It's quite a bit simpler, in my opinion, when using mod_python instead. Either way, it would be awesome if there was a simpler install method.

I'm anxious to see what's you're going to be able to build with Django! :)

#6 · J. J. · May 22, 2006 (17:41)

"...using it for all the websites I've got lined up."

Wow, isn't that overboard?

#7 · Faruk Ateş · May 22, 2006 (17:42)

JJ: why?

#8 · Ooble · May 22, 2006 (19:02)

I've wanted to play with Django for a while now. This kinda tipped me over the edge - now I really want to get my hands dirty. Cheers. :-)

#9 · Fredrik Wärnsberg · May 22, 2006 (19:49)

I'm recently started getting into rails, and I'd like to know why django is better (in your opinion)?

#10 · Faruk Ateş · May 22, 2006 (20:39)

Fredrik:

I'll sum it up in short points, without going too deep into them because that's really a topic for a whole post of its own.

  • Django is Python-based, and I prefer Python as a language over Ruby after looking into both
  • Ruby has a big focus on AJAX, hyped-up products like Backpack, Basecamp etc. - but all at the cost of Accessibility. Django gives you the same programming efficiency, but starts out with a good, clean, accessible basis (depending on whether you know anything of accessibility or not, admittedly)
  • Django is less "magic" and more "Don't Repeat Yourself"-smart, compared to Ruby on Rails
  • I've found Django to be much more consistent, clear and self-conscious than RoR

In the end, though, it's something you really should just look into from both sides and see which one you like best. They're not necessarily better or worse than the other, they're just slightly different. RoR focuses more on creating Web 2.0-style applications that rely heavily on nifty Javascript trickery, Django focuses more on offering you a really quick, clean and efficient way to do website programming, adding features of any kind with minimal effort.

#11 · Jeff Croft · May 22, 2006 (20:52)

I've not used RoR at all, so I'm definitely not qualified to answer, but it does seem that Django has taken more of a backend-only approach (at this point, anyway), whereas RoR mixes in frontend pieces (AJAX with Prototype, effects with Scriptaculous, etc.).

That having been said, there is some work being done on integrating Dojo with Django, so it's possible Django will have some of the AJAX trickery as an optional component in the future.

As someone who knows front-end development and design pretty well, I sort of like how Django stays out of my way there and lets me easily use whatever Javascript libraries I like. Rails, if I'm not mistaken, is pretty heavily tied to Prototype.

All that having been said, I know some people really like RoR's Javascript wizardy, so, more power to them.

Use the best tool for the job -- which is different depending on whose doing the job. :)

#12 · Faruk Ateş · May 22, 2006 (20:56)

Jeff:

Indeed, RoR focuses more on integrating front-end with back-end, and yes it is pretty heavily tied to certain Javascript libraries.

That's also an issue for me: I really don't believe in big Javascript libraries. Server-side frameworks: totally onboard. Big, clunky Javascript frameworks that run up to 200kb??! No way man! That stuff has to be sent to the browser!

#13 · Jan Brašna · May 22, 2006 (22:27)

Jeff and Faruk, I think you gave Rails almost none attention, otherwise you couldn't judge it only from the hype surrounding it. It works (completely?) without the JS overkill, it's only optional thing (to "sell" it to the "Web 2.0 wannabes" who think it's about AJAX widgets maybe?). And if you want to use your own library, use it, or encapsulate it in some kinda helper.

I think the very true point is that you feel Ruby being somewhat wacky and Python cool thus you pick Django. That should definitely be one of the decision points. The rest of the statements seems a bit too trendy for me.

Does this have to be another Mac/Win, Ferrari/Porsche, Java/PHP, Grolsch/Staropramen stuff again?

#14 · Faruk Ateş · May 23, 2006 (00:31)

Jan: nah, I'm perfectly fine with people using RoR - except if they do it in highly inaccessible ways, which even the people from 37 Signals are doing.

Thing is, reading through a bunch of RoR stuff, I never got the feeling they want you to do things right, from the very start. When I read some stuff on the Django site, I got that feeling immediately. They have a lot of good advice in their tutorials and documentation, and that's a philosophy and approach to coding that I really like.

#15 · Luis Caamano · May 23, 2006 (01:08)

Here's a monkey wrench. Have you looked at TurboGears? It's like Rails but in python.

My plone 2.0.5 migration todo list have grown way too big. I've given up on Plone and thus, I've been trying to decide what web framework to migrate to also. In the past couple months I've looked at Zope 3, which is nothing like Zope 2, Django, TurboGears, and Pylons. I've dropped Zope3 and Pylons but still haven't decided between Django and Turbogears. Although I'm afraid that if I wait too long, Pylons might come back into the equation.

The main thing I've learned so far is that making a decision has been waaaay too hard. :-)

#16 · Jan Brašna · May 23, 2006 (02:53)

Sure! This is a valid point, technologies themselves are not bad, only people and what they do with them.

I haven't read the Pragmatic Rails book yet, but from the tutorials I saw I got no impression they were trying to implement some bad practices. You might have been unlucky to come across badly written ones.

Yes, 37s don't give a s**t about accessibility in the apps - does this mean that Rails can produce only inaccessible apps?

Don't get me wrong, I'm not pimping one solution over another (I haven't chosen one for me at all), I just felt you were too quick with examinig Rails, so the comparison might not be accurate, nada mas.

#17 · Jan Brašna · May 23, 2006 (02:57)

By the way, with all those "just add water" frameworks - do you think those PHP ones like Cake or Symfony are usable? It might be so oldskool (since Python and Ruby ones are hot and in for now), but it's way easier to get the syntax for current PHP folks and it's easier to get it hosted as well...

#18 · Daniel Morrison · May 23, 2006 (07:37)

I think a lot of people come to RoR thinking it is "magic" but after you hit a wall or two, you start to understand what's happening and you can leverage this powerful framework. Until you have this "Aha" moment, Rails will only be cool and not amazing.

I have a lot of respect for Django too (though my income is from Rails). I especially like the focus on accessibility. Rails can certainly be accessible, but there is no concerted effort to make it the default.

#19 · Jeff Croft · May 23, 2006 (18:01)

@Jan: You must've missed the line where I said I knew nothing about Rails and have never used it. I prefaced everything I said by claiming ignorance.

#20 · James Bennett · May 24, 2006 (06:05)

Jan, I read the Rails book cover to cover, read through all the tutorials, tried it out more than a few times, and then chose Django.

The reason, for me, is Rails' inflexibility; DHH and most other core Rails developers are very honest about it being an "opinionated" framework, which means that so long as you do things the way Rails wants you to, it makes your life easy, but once you stray from that it begins making things very, very difficult.

Django, on the other hand, has always been pretty easygoing about letting you do what you need to do, rather than what it thinks you should do, and is very actively trying to improve on that (the magic-removal branch was a big step, the current work on supporting multiple auth backends is another, and of course everything's loosely coupled so you can remove or reuse components as you see fit).

#21 · James S · May 24, 2006 (06:13)

I think you're being a bit hard on Prototype. For one thing, it's nowhere near 200kb. The current version (1.4.0) is 48kb and that includes comments and hierarchical formatting. I have no doubt that running it through jsmin or some similar utility could strip out another 15-20kb.
I've found that Prototype signifigantly helps my js development efforts. If you find its features useless, then by all means don't bother, but I don't think it's size is a probem. The ony legitimate gripe I've found is that it adds some methods to Array.prototype which change how for...in works. My feeling about it is that 95% percent of people complaining about this ought to be using objects for key=>value pairs anyway. I've always been a big Ruby fan, so maybe it's not surprising I like Prototype, which implements some of Ruby's built-in classes in JS. Now script.aculo.us is another story...

#22 · Faruk Ateş · May 24, 2006 (09:12)

James S: I think I wasn't clear back there. I didn't mean to say that Prototype was 200KB; Prototype is a Javascript library that most all of my JS-writing friends have cursed about. Then there are other libraries that run up to 200KB, which make them useless for me from a filesize point of view.

#23 · Jan Brašna · May 24, 2006 (11:57)

Yes, I felt that difference, thanks for confirming, James.

#24 · James S · May 24, 2006 (13:21)

Faruk: Perhaps you could share what it is your JS-writing friends don't like about Prototype? I'm curious. I don't hold any special brief for it, but I do use it myself. Maybe there's some downside I'm missing. As far as ROR is concerned, prototype and script.aculo.us are the only javascript libraies it uses, to my knowledge. And scriptaculous is optional: if you don't care for it's large size, don't use the 2 ROR ajax helpers that require scripaculous: auto complete and drag-and-drop.

#25 · Faruk Ateş · May 24, 2006 (13:33)

James: the last experience was two weeks ago when a die-hard programmer friend of mine told me how he had to use Prototype for work, and ended up having to fix over a dozen severe bugs in the library before he could use it.

Bugginess is the biggest issue I hear about Prototype. Unreliable behaviour, stuff not working, etc.

#26 · Alper · May 24, 2006 (15:07)

Great stuff seeing Django more widely adopted. I'm thinking about building a site with it in the near future myself. My blog is hosted on a Zope based product and it is causing me too much grief recently.

@designers: In his XTECH talk, Simon Willison also gave the point about designers without much programming background making awesome sites with it. For these kind of people having a simple interface to a database-based web framework is key.
Having a very solid understanding of HTTP or of SQL or other relational theories is not very important to them. It's just important that the framework is a good fit and doesn't give rise to too shoddy programming.

@PHP: Seeing how you can get a complete admin interface (aka Content Management System) in Django with the flip of a switch, it makes me kind of sad seeing that everybody who's anybody in PHP feels the need to build their own 'cms'.

@modular: Django's modularity makes it easy to build upon the jungle of Python web solutions which are already available.
I don't really see why you shouldn't be able to swap Django models out for either SQLObject or SQLAlchemy. Though that would somewhat preclude using the admin interface.
Equally simple would be swapping out Django's templates for a favourite templating system of your own.
Not that there is really any necessity to do either one, because Django (like Python) comes with batteries included.

@prototype: I read through the Prototype docs once and I can immediately understand why you would want to use it. It's dead sexy from one point of view. My programmer's gut tells me that altough Prototype may be tempting, Dojo is the way to go. It looks so much more solid and I trust the guys from that team to take the incompatibility arrows in the back for me.
Testifying to that work is underway to offer some level of collaboration between Django and Dojo.

@cons: You're right that the install isn't immediately obvious to non-Python people. It could be easier. I set up a dev environment on my laptop using SQLite. Hardest part of that was compiling a compatible pysqlite module.
The error pages have already had quite some work, but I can see how you still think they are intimidating.

#27 · James S. · May 24, 2006 (23:44)

Faruk: point taken about prototype bugs. I've run into a few myself (though not as many as your programmer firend) but in these instances I was able to fix the bug or work around it. Even with this added hassle (which was slight), I still found it to be a time saver.
Alper: Dojo looks cool too, but I think your comparison is kind of apples to oranges. Dojo seems to be a great toolkit for animated effects, drag and drop and other UI widgets. In this respect, it's really more like scriptaculous or rico. In fact, I think I'd probably choose it over either of thse two. But Protoype does not offer any of these things. Instead, it's a framework that imports some useful programming paradigms into JS and smooths over some of the rough edges of DOM/JS interaction. True, it's basically just Sam Stephenson running the show, but he's got a huge community of rails users behind him and bug fixes are pretty timely.

#28 · Seth Thomas Rasmussen · Jun 9, 2006 (02:11)

Interesting food for thought, as usual, Mr. Faruk. I was gonna add my thoughts, but I somehow brought your comment form to its knees. Muwaha.. also, my thoughts become kind of verbose for a wee comment.

So, for you and anybody else interested: my thoughts

:)

#29 · Seth Thomas Rasmussen · Jun 9, 2006 (05:10)

James S: I hadn't heard anything about Prototype messing with the for-in loop, but if you're using Prototype, one would think you'd opt for each() anyway. My guess would be that they finagled something for that which messed with the loop behavior, but I have no idea.

#30 · Lisa · Jun 16, 2006 (20:00)

Hi, i have a random question coming from someone who has a minimal programming backround. For an internship i'm in, i need to find out which one (if either) - turbogears or django can use exisiting databases for the model, or if they require that you create your own?

#31 · Faruk Ateş · Jun 16, 2006 (23:28)

Lisa,

I don't know anything about Turbogears, but with Django you can build sites based on existing databases. I haven't done it myself so I don't know if you have to migrate the data or can just plug the existing data into a specifically tailored Django installation, but I know that you can build on existing databases in some way.

#32 · lisa · Jun 19, 2006 (22:28)

thanks Faruk!

All times are in CET. It is now 19:44.