On 31 Aug 2006 08:24:29 -0700, Adam Jones <[EMAIL PROTECTED]> wrote: > > 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. > yes indeed as someone said earlier the support is already there and all that needs to be done is a migration path. > > > > > > > + 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. > either that or all the hipy of RoR will go away. > > > > > + 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 for javascript you have mochikit which is really nice. > > > 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. >
I believe that is the most important part of TG, taking the best of the best, and letting the framework adapt and morphe. for example noone plan to move to SA, 0.1 came out a couple of people took and look and like it, then 0.2 was "mature enough" so people started thinking about the migration. after that some code was made and now we have TG with SA, eventually it will be the default. Same with templates, kid is really weak at generating non-xml, it has a plain text serializer but the input must be xml so that's overkill. So a new template frontend (chettah was born). Someone ones said on the mailing list TG is the Ubuntu of web frameworks, and I think I'll add and you can strip down the kernel and it wont break :) > -Adam > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
