TurboGears 2.1b1 released and updated on the openSUSE build service

One-Click Install TurboGears 2.1?

You can now One-Click Install TurboGears 2.1 Beta 1 directly from the openSUSE build service. Just click here!

2.1b1: (**January, 25 2009**) ¶

• Deprecated default in favor of _default
• Fixed handling of Unicode parameters
• Added disable_request_extensions flag to configuration to allow users to ignore the request extension dispatch bits of object dispatch.
• Increased length of Permission.permission_name to 63 chars.
• Fixed GET requests on nested RestControllers?.
• Fixed case-sensitive incorrectness in quickstart when using mako template option.
• Fixed numerous URL routing bugs, consilidating the RC and TGC controller base.
• Fixed eroneous tg.url call inside the quickstart template.
• Added use_dotted_templatenames support for Genshi.
• Added ignore_parameters setting in the config
• Added ability to have sa_auth.cookie_secret in .ini file
• Added cookie_secret to quickstart template
• Added tgext template
• Added backwards compat for TurboJson?

File uploads using with ajax using jquery.form and TurboGears 2.1

While trying to follow the ajax file upload example from http://jquery.malsup.com/form/#file-upload I was running into trouble with the server response. I was expecting the server to return json, which I wanted to parse in a callback function. What happened was that the server did its job perfectly and returned content-type application/json. However, the browser (in this case Firefox 3.5) prompted me to download the response, rather than to parse it in the callback function. This is obviously useless.

The answer was to return content-type text/plain instead of application/json. To do this in TurboGears 2.1, I followed an example from Pylons. My controller now looks like this:

   @expose()
    def uploadFile(self,**kwargs):
        """ Simple controller to handle uploaded files

        """
        # do stuff such as handle file upload...
        response.headers['Content-type'] = "text/plain"
        return dict(info={'filesize':50000,'filename':'whatever')

Note the response.headers['Content-type'] = "text/plain" - and that I left out the expose('json') which you would normally use in TurboGears to return json...

TurboGears2 application using Apache and mod_wsgi

Here are the steps I went through to get a TurboGears2 application running using Apache and mod_wsgi. It assumes that apache2 and mod_wsgi are configured and properly set up (don't forget to a2enmod wsgi in order to load the wsgi module). There is a good example documented at http://www.turbogears.org/2.0/docs/main/Deployment/modwsgi+virtualenv.html

Install the required packages:

zypper in apache2
zypper in apache2-mod_wsgi
zypper in python-wsgideploy

Create a new turbogears application using paster. This one is called labum

paster quickstart labum

Go into the newly created application root folder

cd labum

Create an apache wsgi setup for the application

paster modwsgi_deploy

Go into the newly created folder 'apache'

cd apache

Edit the labum.wsgi file to suit your environment. I quickstarted the labum application in the
folder /home/cfarrell/Dokumente/labum, so I need to remove the default references to /usr/local/turbogears. I do this in vi using

:%s/\/usr\/local\/turbogears7\/home\/cfarrell\/Dokumente

Copy the the file 'labum' in the 'apache' directory to the apache2 configuration directory. On openSUSE this worked (all *.conf files in /etc/apache2/vhosts.d/ are auto loaded by apache):

cp /home/cfarrell/Dokumente/labum/apache/labum /etc/apache2/vhosts.d/labum.conf

Go back into your turbogears application directory:

cd /home/cfarrell/Dokumente/labum

Copy your development.ini file to production.ini and remove the debugging by setting
debug = False in the first couple of lines

Reload apache and go to http://localhost/labum. If everything worked, you should now be able to see your TurboGears application. If it didn't, you should see what happened by looking at

/var/log/apache2/errors.log