class NewsController @articles = Article.find_all end

end

import cherrypy

import turbogears

from turbogears import controllers

import model



class News(controllers.Controller):



@turbogears.expose(template="news.templates.index")

def index(self, **kw):

return dict(articles = model.Article.select())



class Article < ActiveRecord::Base

end





class Article(SQLObject):



title = StringCol(length=200)

maintext = StringCol()

created = DateTimeCol(default = datetime.now)

category=ForeignKey("Category")

author = ForeignKey("User")





I first glanced at Ruby a few years ago, round about the time I first glanced at Python. The two were, at least superficically, similiar. As I was more heavily into web development at the time Python looked the better option because of Zope, WebWare and other packages; Ruby then (as far as I know) just had plain CGI.Now Ruby has stormed the web development world with the Rails platform, leaving Pythonistas dazed and confused. Nevertheless we rallied round two excellent packages, TurboGears and Django, while the Zopeheads worked on their interesting but rather esoteric Zope 3. And Python is not short of web development platforms; I wrote a large document management application using Quixote + Durus, about which more later. But Ruby, once an obscure Japanese cousin to Python, is now the darling of the tech media.Rails has been around now for about 15 months, 3 times longer than TurboGears (though not TG's individual components) and so I decided that as a more stable platform it would be worth a look. Plus, and this is something I forgot to mention in my last post about Java, you should always look for possibilities to beef up your resume with buzzwords. Even if I just wrote a little wiki for handling work projects in Rails I could put that on my CV. Such is the benefit of hype.Others have written on the differences between Ruby and Python; I'll not add to that here, except that it was in a way harder to switch between Ruby and Python than between Python and Java, because the small differences in syntax keep catching you out. Anyway, on to Rails.The immediate first impression is that TurboGears is more verbose(or explicit, if you like) than Rails. For example:RoR:TG:One thing to note is how you have to tell TG what methods to expose to the web, which template to use, and what data goes in the template. In RoR this is decided for you; every method by default is exposed, any data in the method goes in the template, and the name of the template is the same as that of the method (in this case, index.rhtml). You can override these, but a lot of assumptions are made on your behalf.Let's look at how each system handles the model:RoR:TG:Again RoR's ActiveRecord works implicitly: it looks for a corresponding database table and maps rows to Article objects. With SQLObject you define the columns in Python code and then the object creates the corresponding database table as needed (in this case, Article.createTable()). You can do things the RoR way in SQLObject, but in general this is only done with legacy databases.This is the basic difference in philosophy between the two platforms. The Pythonic way is "explicit over implicit". Everything is out for show: you know what modules are imported, you know what methods are exposed, you know what columns are defined and so on. It may take more keystrokes but the extra code let's you know what is happening when things go wrong. The Ruby way (or at least the Rails way) is the opposite: take the burden off the developer, don't bother them with the petty details that get in the way and add to the line noise.RoR does make for more readable code. However, there is a caveat: when things go wrong, or when you want to do something different, it's a lot more work to fix the problem than if it's always obvious what's going on. In that way RoR is the anti-J2EE; it assumes everything for you. I can see the advantages, but I also find it annoying and presumptious: I want to decide upfront what methods to expose and how my data model should look. In fact, Zope has inspired such hatred amoing Pythonistas for just that reason: things like acquisition doing mysterious business behind the scenes that cannot be explained, which is lovely when it works but a source of immense frustration when it doesn't.Finally, one should also consider features available in TG that are not in RoR and vice versa. TG has the Toolbox, an over the web admin application that comes with a set of goodies like a relational model designer and data browser, localization tool, and so on. More importantly, it has good internationalization support, including localized date formatting and the like. This is really, really important if you work in Europe: in Finland,for example, I often have to develop sites that are available in Finnish and Swedish (Swedish is Finland's second official language) as well as for example English, Estonian and Russian. I'm not sure how well RoR supports internationalization.Both have form widgets, though in different ways: RoR just uses simple functions in templates, whereas in TG you create form and widget objects and insert them into your templates. RoR uses ASP or PHP style text-based templating, TG uses Kid, an XML-based template engine that ensures well-formed HTML or X(HT)ML. RoR has scaffolds, TG has DataControllers. Which features you need and which is the better way of doing things is again down to requirements and preference.In summary, both are well-designed and fun to work with. Both kick Java's fat corporate ass. They have different approaches to the same problem, but that's OK:I like the Pythonic way of TurboGears but I can see that others prefer RoR's magical implicitness. RoR has better marketing which makes it easier to persuade your boss to let you use it. It is also more stable, being in existence 3 times longer than TG, but TG makes use of well-designed, mature components like CherryPy and SQLObject. Python has more libraries than Ruby, Ruby has nice features for closures and the like. As always, YMMV.My next comparison will be TurboGears vs the various Python web development frameworks.