Jaroslaw Zabiello wrote: > [EMAIL PROTECTED] wrote: > > > + SqlObject allows working with the DB tables without > > using SQL itself. > > Rails has ActiveRecord ORM, which IMO has nicer and simpler > syntax than SQLObject. Rails has migrations, TB - not (Migrations is > versioning system for evolving database schema)
I don't really see TG sticking with SQLObject. In moving to SQLAlchemy it would pick up not only a migration system but also a much more flexible abstraction system due to the use of a Data Mapper pattern instead of the Active Record pattern. There already is an implementation of Active Record on top of that, so that benefit stays as well. > > > + Likely to be faster because as far as I'm aware, Python > > is significantly faster. > > Python is maybe faster, but with YARM (which is not stable yet) Ruby > will be about 10x faster. YARM is full virtual machine like Java. I tried to check out information on this, but the only docs I found that looked like what I wanted were written in japanese. Do you have any links discussing the status of this project? Does it make any breaking changes to the Ruby implementation that will have to be fixed? Has the RoR project already agreed to port to this when it is stable? > > > + Easy access to other libraries (such as the Python > > Imaging Library) that Ruby, being a relatively newer > > language, doesn't have equivalents to. > > Ruby is not so young you think. It became more popular > when Rails has appeared. Although that is true there are not as many libraries available for Ruby as there are for Python. This will probably change as the language gains popularity, but for right now it pays to look into library support before considering anything else about the language. > > > + I find the templating system somewhat cleaner; code in > > py: xml namespace allows pure .html templates, instead > > of equivalent of .rhtml files. > > But rhtml is much more flexible because it can generate *any content*, > not only xml. But Rails has THREE template systems: rhtml (main), rxml > (for rss and xml generation) and rjs (for javascript and AJAX). Kid can be used to generate xhtml, rss, xml, pretty much anything that is xml-based. I have even seen it used to generate xul applications for firefox. The only thing on your list that it doesn't do is javascript. Personally I would rather learn one templating language that is able to treat all of my xml as xml no matter what use it is put to. > > And last but not least, TG is based on poor, unstable and buggy > CherryPy server. We had huge problems with CherryPy. I think that > Django or Pylons are much better frameworks. IMO TG is no competition > for Rails at all. The only real competition is Django or Pylons. I have never had much in the way of problems with CherryPy. From what I have heard the project has made a lot of improvements recently, so it may have changed since you last took a look at it. Actually that point right there is where I think TG is a lot more competitive that you believe. When a new version of any of the foundation projects comes out, or a better project to fill that particular need, TG can absorb it in the next version. The TurboGears developers can spend most of their time working on additional code that makes the project more useful instead of bug fixes and minor feature upgrades to the core components. This philosophy is proven to work for most other open source projects, and I have yet to hear a good argument why it would not be successful for a web framework. -Adam -- http://mail.python.org/mailman/listinfo/python-list