On Thu, 2006-08-31 at 23:31 +0200, BJörn Lindqvist wrote: > On 8/31/06, Jorge Vargas <[EMAIL PROTECTED]> wrote: > > On 31 Aug 2006 08:24:29 -0700, Adam Jones <[EMAIL PROTECTED]> wrote: > > > > 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 :) > > But that is not really true. If you use Cheetah instead of Kid, you > lose out: No widgets,
Untrue. Even though I don't use widgets much myself, I wanted to make sure they *could* be used with TurboStan, so I did a quick test with Kevin's autocomplete widget. Worked fine. I can't see why Cheetah would be any different. > no auto-generated code What auto-generated code? The example templates that you get with quickstart? Hardly a loss. > and the (incomplete) > documentation won't apply anymore (it assumes Kid templates ofcourse). True. However I've had little trouble translating from Kid to Stan (and that's probably a longer jump than from Kid to Cheetah). > If you use SQLAlchemy instead of SQLObject, no identity framework, Completely false. > no administrative tools (tg-admin sql, True. > CatWalk etc True. > ) and no documentation. Partially true. The documentation exists but some of it is out-of-date and it was never very complete to begin with. Of course, like many OSS projects, the mailing list is your best resource and SQLAlchemy itself has quite good documentation. > If you use prototype instead of MochiKit... I have no idea what > happens You get Prototype instead of MochiKit. > and using another webserver than CherryPy isn't possible right > now, I guess? Not that I'm aware of. Nor do I think it would make much sense since CherryPy is the heart of TurboGears. I typically use CherryPy to serve the dynamic content and a real webserver (Nginx) to serve static files. I've never felt this was a handicap. > In fact, if you decide to replace so many modules that TurboGears > depend on, what do you gain in using TurboGears at all? If you got to the point where you were replacing more parts than you were using, then you'd certainly want to find a different framework as TurboGears is clearly not for you. I fail to see your point. Personally I've chosen to go a different route on a couple things and leave the rest intact. I expect most people are the same. With most frameworks, there's typically one or two things most people don't like and it's nice to be able to replace those things without a lot of fuss. I don't see how that's a liability. > It seems like > the TurboGears developers have a lot of work to do, (and a lot of > documentation to write) if they want to make their framework as easy > to use as others (ie: Django) that takes a more holistic approach. That's odd, because I've actually used both and found TurboGears far easier to get started with (no mucking about with Apache and mod_python for one thing, no need to setup explicit url regexes just to get "hello, world" on a page). Judging from your above comments it sounds to me like you're mostly speculating about TurboGears. > TurboGears more seem to be like emacs than Ubuntu - infinitely > customizable... Not quite enough IMO, but close enough. > In the future both Rails and TurboGears will probably be great. But > since someone mentioned Rails moving to YARV, and TurboGears moving to > SQLAlchemy and Markup, it seems to me that they are both in a state of > flux and not quite ready yet. TurboGears is certainly in a state of flux although from an outside (i.e. API) standpoint it's not nearly as bad as you might think from the changes that have gone on under the hood. There's been only a few breaking changes up til now (I converted a site I'd built on 0.8 to the latest SVN last night and most of the issues I encountered were with my own changes to TurboStan). Regards, Cliff -- -- http://mail.python.org/mailman/listinfo/python-list
