After looking at Ruby on Rails a bit more closely, I responded to a comp.lang.python thread on it. I thought I'd copy my thoughts here:
I've looked a little at Rails. It's not super special. Well, it is compared to things like Java; dynamic languages are quite superior for rapid development of websites, and Ruby and Python are similar languages in that way.
Rails is really a whole stack that works well together. People have been writing this sort of thing in Python for a long time; which isn't to say they always have gotten it right, or that those efforts have had the right perspective to be strategic successes (i.e., become popular).
Lessee... Rails seems to have:
All three of these pieces fit together really well in Rails, which is perhaps what it offers that Python doesn't have. Well, I'm sure some framework out there has this, but it's hard to say, there's so damn many.
But, while this is really compelling when you show off the creation of a simple system, I suspect it becomes a fair amount more complicated later on. At least, that is my experience with Python projects of similar ambition. It's neat to setup a database and have it work instantly, complete with the standard CRUD forms. But this only works for "leaf" tables, and even then no so well. How do you deal with joins? How do you deal with complex requirements on input, or actions on updates? Eventually you'll need to tweak a generated form just a little, does that mean you have to throw away all the automated aspects and code it by hand?
I don't mean to criticize Rails with these questions; it's not that Python frameworks solve these wonderfully either, these are just hard problems. But for realistic web applications these are inevitable issues, and I suspect Rails isn't quite as compelling when you take them into account.
OTOH, I'd love to see something in Python that is just as tight as Rails, but uses all the pieces we've already developed. It's really just a question of sticking pieces together; but that's a surprisingly difficult operation.
FWIW, Zope 3 attempts to tackle virtually all of these matters, with the exception of SQL mapping. AFAICT, Zope 3 doesn't have O-R mapping in its goal set, however.
Of course, you're probably aware that PEAK is also attempting to tackle these matters, but with robust handling of "legacy" databases, and schemas and forms that have complex constraint validation.
Both Zope and PEAK already have nice MVC mechanisms, object publishers, and templating systems.
Anyway, "sticking pieces together" won't cut it, IMO. You can cut pieces of wood from a tree, but you can't make a tree by hammering pieces of wood together. :)
I've had a small amount of success using Cheetah, CherryPy and SQLObject together. The three products seem to complement one another quite well. In Phillip's terms, you can't make a new tree, but you can fashion some rather nice furniture. ;)
Rails is certainly much different than Zope 3 or PEAK; the ambition is much lower, and the accompanying conceptual hurdles are also much lower. I don't know which has more potential; Zope 2 shows that merely building an integrated environment does not mean it will be good. Obviously both Zope 3 and PEAK are informed by those mistakes, but the basic vision hasn't changed; at the same time, Rails (and several other similar efforts) are a very different, and more modest, vision.# Ian Bicking
Rails has some weaknesses, but your post is missing them, Ian. Several people have had the reaction "but what if you want to do more than simple scaffolding?" but it totally misses the point. Scaffolding is just a development aid to get things online quickly. You'd never use it as a finished product. Doing joins and more complex screens is still easy.
The integration within Rails goes very deep, yet it retains flexibility. That's something that can't be achieved by sticking pieces together, as Phillip noted. If you want a Rails-like framework in Python, I suggest you get your hands dirty and start from scratch.
# Gavin Sinclair
Rails are amazing. I wish there was more docs and tutorials and books. It’s difficult to learn it from scratch without much information.
I am using Quixote and SQLObject with MySQL underneath.
With the exception of session managemnt, which is lousy in Quixote, this works pretty well. I build a HTML-layout with an abstract Python class, coded in PTL. Every web page that is using the template, is a subclass of that abstract class, which results in structured, easy to maintain site. The startup code was bad in Quixote 1.x but is much improved in 2.x, giving me the opportunity to switch from medusa during development to apache + mod_scgi for deployment
I'm researching a framework for a code rewrite of a large web application. I've been pointed at Rails and Zope. I have no experience in either so I have a fresh perspective on them. I haven't found much decent documentation on Zope 3. There's plenty of it though. The whole design to me seems sloppy and more like a dirty hack to encapsulate MVC and other ideas. Zope does tout a larger user base and a more extensive set of components. It isn't at all clear how everything works in Zope due to the lack of any good documentation. Now, Rails on the other hand is very well documented and it is kept up to date. The Zope docs seems to be rotting. Rails takes MVC and seems to shape itself to that pattern. It's clear almost immediately how things work and where to begin. I feel we could easily start using Rails and all feel very comfortable in it. Zope on the other hand seems to have a quite steep learning curve which I mostly attribute to a lack of good documentation. Rails seems to embody a newer style of web development whereas Zope has a more legacy feel to it. Our project is quite large and is funded for 12 years so I want something that won't need to be rewritten anytime soon. Zope just doesn't have the enormous forward momentum that Rails does right now. Rails is only going to get better. Zope 3 is still stumbling around trying to fix their previous problems with Zope 2. In my opinion, Rails is the best framework I've seen thus far.
# Brian McQuay
Django is your friend http://www.djangoproject.com/
# Philippe J