From: Hal Fulton <hal9000@...>
Date: 2006-08-28T05:44:14+09:00
Subject: Re: Pros/Cons of Turbogears/Rails?

Kenneth -- a few comments below...

My knowledge of Rails is slight, so others may
contradict me. If so, they are likely right.


kenneth.m.mcdonald@sbcglobal.net wrote:
> First, I don't intend this to be a flame war, please. Python
> and Ruby are the only two languages I'd willingly work in
> (at least amongst common languages), and TurboGears and
> Rails seem roughly equivalent.
> 
> I'm much more knowledgable about Python, but that's a minor
> issue--I've been intending to learn more Ruby anyway.
> 
> Here are the pros and cons that I'm aware of and consider
> important:
> 
> Turbogears:
> + SqlObject allows working with the DB tables without
> using SQL itself.

Rails can do this.

> + Likely to be faster because as far as I'm aware, Python
> is significantly faster.

Perhaps. If you do measurements, share your findings with us.

> + Easy access to other libraries (such as the Python
> Imaging Library) that Ruby, being a relatively newer 
> language, doesn't have equivalents to.

I don't know what that is, but we do have RMagick, which
binds to GraphicsMagick or ImageMagick.

> + Built-in default SQLite makes it easier to set up?
> (as far as I can tell, Ruby requires MySql by default--don't
> know how easy this is to change.)

Ruby can do SQLite. I think Rails makes it pretty easy to
change databases.

> + I find the templating system somewhat cleaner; code in
> py: xml namespace allows pure .html templates, instead
> of equivalent of .rhtml files.

Matter of taste. I don't have an opinion really.

> Ruby:
> + More mature system. More stable? More features?

Perhaps. I know *nothing* about TurboGears.

> + Much better documented. This is a biggie.
> + Built-in Rubydoc system would make documenting the
> system easier. (IMHO, developers almost always
> underestimate the need for good documentation that
> is written along withe the system.) Is there a
> Python doc system that has received Guido's blessing
> yet? D'oxygen would seem an obvious choice.
> + Better coordination with Javascript helper code?

Did you mean RDoc?

> 
> I was initially leaning towards Rails due to maturity,
> but the most recent version of TurboGears seem to have
> fixed a lot of the "ad hoc" feeling I got from previous
> versions. But I'm still very much up in the air.
> 
> Thanks,
> Ken
> 
> P.S. If I wanted to provide an image by streaming the
> file data directly over the connection, rather than by
> referring to an image file, how would I do that? I'd
> like to build code that would allow images to be assembled
> into a single-file photo album (zip or bsddb file), and
> so can't refer to them as individual image files.
> 

Hmm... I did this once. Had something to do with the content-type.
It's usually text/html or text/plain, but if you change it to
the proper string and set the content-length appropriately also,
I think it Just Works.

You might try the old trick of telnetting into a web server on
port 80 and pretending to be a browser. (If you can remember
exactly how to do this; I don't). Use a URL that points directly
to a small image and watch the stuff you get back.


Cheers,
Hal