Taking just the current documentation TG2 has less features for a new developer than TG1 – there is no information how to get user information from the repoze thingies anywhere in the docs, for example.

Perhaps this is improved in newer versions of cp3, but it used to be running one cp3 app inside another was not a supported configuration.

@Alberto: Thanks, I’ll be on the lookout for flying beasties. You’re the only person I’ve seen defend Pylon’s StackedObjectProxies [1] without raising hand-waving to an Olympic sport, which is appreciated.

I’m still having a hard time imagining a case where a threadlocal needs to be modified without being observable downstream, however. Also, even if I stretch my brain to include that need, it seems that there should be a way around it by mangling environ keys. While not exactly pretty, that would at least put the complexity where it belongs — close to the complex app, not left out in the open for everyone to suffer over.

So, got a testcase or small app that I can wrap my mind around?

[1] http://groups.google.com/group/pylons-discuss/browse_thread/thread/12d94d885c476931/

I love the sound of this. There is nothing wrong with healthy competition. This is a great way to compete with other frameworks, and do something meaningful at the same time….write the best docs! I look forward to seeing the results. Does this mean a TG2 book is in the works?

> I assume your talking about use_wsgi_app() here. I’m working on
> backporting this to 1.5. Right now my implementation is a bit too > clever, but I should get that worked out soon. In the meantime,
> it’s not too big of a deal to just set it up via configuration.

Beware of the dragons around here… Unfortunately CP3′s threadlocals aren’t stackable like Pylons’ so, although TG1.5 dispatching to a WSGI app will work most of the time, it won’t work if the other app is a TG1.5 or CP3 app because the threadlocals will be overwritten.

@Mark:

Congrats on the new release! I can’t wait until we have a less scary beta I can point some people who’ve been asking at python-es for a python web-framework to dive into webdev.

I don’t want to imply that TG1 is not developing quickly, and I’m actually pretty hopeful that almost all of these things can be back-ported to 1.5 or 1.6 so that the differences between 1.5 and 2.0 can continue to get smaller.

Mainly I have had people asking why TurboGears 2 exists when Django is moving so quickly, and this was a list of things that I like about TG2 that are useful and were not easy enough in 1.0 — but which may very well be in later 1.x releases.

A couple of other things:

* We aren’t using evalexception we’re using weberror, which is “just” a newer verion of the same thing, and that could be used in 1.5 easily enough.

* Webhelpers wouldn’t be too hard to use in 1.5 if we wanted too.

* 1.5 can pretty easily use beaker for intermediary data caching, and support the same API as tg2.

I’m very much looking forward to TG 1.5, and I’m very excited to see that things are progressing so quickly on that front.

However, TG1 isn’t standing still, either:

> * Out of the box support for a powerful web-based
> interactive debugger

Are you using a different debugger than paste’s evalexception? (Which tg 1.0 uses.)

> * Full WSGI support

TG 1.5 picks this up by being virtue of being based on CherryPy 3.

> o Your app is a WSGI app out of the box

In 1.5, your controllers are plain ole python objects. You get a wsgi app back when you mount them.

> o You easily call a any WSGI app from inside TG2

I assume your talking about use_wsgi_app() here. I’m working on backporting this to 1.5. Right now my implementation is a bit too clever, but I should get that worked out soon. In the meantime, it’s not too big of a deal to just set it up via configuration.

> o You can easily create and add middleware to your
> TG2 app

In CherryPy3 / TG 1.5 this is done either through configuration or by calling `myapp.wsgiapp.pipeline.append`.

> * Easy access to a large library of helper functions
> in your templates

WebHelpers.. yeah, haven’t looked at it.

> * Out of the box support for using Routes to overide
> object dispatch for unusual URL’s

http://tools.cherrypy.org/wiki/RoutesUrlGeneration

> * Flexible out of the box caching for pages,
> intermediary data, etc

tools.caching.on for pages, haven’t thought about intermediate data.

> * Improved object dispatch, to better support resource oriented URL’s

Yeah, that’s some good stuff. We should look at backporting it.

> * Support of Dojo, jquery, ext.js, mootools, and other
> javascript libraries via ToscaWidgets

Aren’t people using ToscaWidgets with TG 1.0 today? As for myself, I’m still waiting for either someone to document the API differences with TG1.0′s widgets, or the time to figure it out the hard way.