July 31st, 2008 by Mark Ramm
We just cut another release for 1.9.7a3, and it’s even more backwards compatable with TG1.
I occasionally get questions about why we are working on version 2.0 of TurboGears and what it means for users.
- The ability to retrieve whole graphs of objects in a single query through the ORM
- Commit entire graphs of object changes back to the database in one step
- The ability to support multiple databases easily
- Out of the box support for a powerful web-based interactive debugger
- Full WSGI support
- Your app is a WSGI app out of the box
- You can run multiple TG2 apps in a single process
- You easily call a any WSGI app from inside TG2
- You can easily create and add middleware to your TG2 app
- Easy access to a large library of helper functions in your templates
- Out of the box support for using Routes to overide object dispatch for unusual URL’s
- Flexible out of the box caching for pages, intermediary data, etc
- Improved object dispatch, to better support resource oriented URL’s
This means that TG2 apps have more flexibility and can can scale better than TG1, and we’re working on trying to make TurboGears 2 better documented than any other framework. Because we have full WSGI support you can easily mount existing WSGI applications in your TurboGears site, and you can also get things like profiling middleware, middleware that helps you find memory leaks, or any of a whole host of other interesting middleware almost for free.
There’s lots more to be done before we hit 2.0 final, we need to transparently support attomic commits across database boundaries (when the underlying stores support it). We need to make it even easier to build reusable site-components with TG2, and we need to continue to improve the TG2 documentaiton.
But I think we’re making huge progress, and I’m looking forward to the next release. The current plan is to release a 1.9.7 stable release in the next 4-8 weeks, and to release 2.0 (with the above mentioned extra features) later this year.
July 26th, 2008 by Mark Ramm
I think virtualenv is horribly useful, because it is very, very common that I want to use more than one version of a library. Sometimes this is just because I want to test TurboGears 2.0 against some new version of some dependency, sometimes it’s because I’m running some old version of some project with out-dated requirements, and other times it’s just because I want to key my OS’s system python clean. Because there’s lots of virtualenvironments on my machine, and because I’m always switching between them I was very happy to find Doug Helman’s article on how to more easily manage switching between the various virtual environments that I’m working on at any given point in time.
If you use virtualenvs — and if you’re a python developer you should ;) — take a look at this article, it might make your life easier.
July 25th, 2008 by Mark Ramm
Here’s a quick note on how to use IIS to serve up your TurboGears applications. This is something we need to document better, if we want to increase python/turbogears penetration in the windows market.
It’s not like asp.net is so good that they don’t need TurboGears. And TurboGears multi-threaded+multiprocess model works better on windows than many of the other “dynamic language web-frameworks which depend solely on the multi-process model.
July 23rd, 2008 by Mark Ramm
Very useful cache decorator for TG1.
Not sure how I missed this one, but it’s definitely worth a look for anybody trying to scale a TG1 application.
July 23rd, 2008 by Mark Ramm
TurboGears has used a tree of controller objects to do URL dispatch since 1.0. Which is nice and easy to understand, and makes getting started very quick. But, it wasn’t always apparent how you should use it to do RESTful dispatch, since the HTTP verbs all ended up going to the same controller method.
You could dispatch within that method, but that never felt totally clean to me. And I’ve been thinking and talking about better ways to do this. The good news is that Rick Copland just “made it happen” after a conversation in atlanta last week.
Using his trick you can write code like this:
def get(self, **kw):
return dict(method='GET', args=kw)
def post(self, **kw):
return dict(method='POST', args=kw)
# NOT exposed
def delete(self, **kw):
return dict(method='DELETE', args=kw)
And then HTTP GET and POST verbs will be routed to their respective methods. This makes working with RESTFul api’s easier. And on that front I’m very much looking forward to Dojo 1.2 which has all of kinds of restful json data store goodness.
Hopefully Rick’s recipe can find it’s way into the 1.x core code somewhere so that it’s even easier to do. But for now a couple dozen lines of code gives you everything you need for RESTful goodness.