Pros/Cons of Turbogears/Rails?

[Jorge Vargas]

On 8/27/06, kenneth.m.mcdonald at sbcglobal.net
<kenneth.m.mcdonald at 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.
yes and SQLAlchemy lets you do more complex things, like working with
an existing database.
> + Likely to be faster because as far as I'm aware, Python
> is significantly faster.
no idea there.
> + Easy access to other libraries (such as the Python
> Imaging Library) that Ruby, being a relatively newer
> language, doesn't have equivalents to.
python's'lib is MUCH more bigger

> + Built-in default SQLite makes it easier to set up?
actually no you still have to install sqlite and the "build in" is
just a config entry.
> (as far as I can tell, Ruby requires MySql by default--don't
> know how easy this is to change.)
> + I find the templating system somewhat cleaner; code in
> py: xml namespace allows pure .html templates, instead
> of equivalent of .rhtml files.
>
> Ruby:
> + More mature system. More stable? More features?
not at all, you could say that in a TG vrs django or zope.
> + Much better documented. This is a biggie.
TG docs are lacking at the moment mainly due to a problem with the
documentation engine, we have been bouncing between trac,docudo, xmls
and now moinmoin. this will be settle soon, until this is fix there
will be on 1.0 (which may be the reason why RoR is already out and TG
isn't)
> + 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.

huh? docstrings ...

> + Better coordination with Javascript helper code?
again huh, in TG you include a JS lib and it's done. if someone has
made a widget for it all you have to do is install it (easy_install
widget).

>
> 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.
is that 0.5 and 0.8? almost everyone on TG runs the 0.9 alpha's there
has been so much code in to them that is stable as a rock.
>
> 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.

if that's the case either is just overkill all you need is a simple
httpserver and reading a bit about image encoding.

> --
> http://mail.python.org/mailman/listinfo/python-list
>