Ann: CherryPy-2.0-beta released

[remi]

Hello everyone,

I am happy to announce the release of CherryPy-2.0-beta.

CherryPy-2 is a pythonic, object-oriented web development framework.

CherryPy-2 is a redesign of CherryPy-1 (the unpythonic features have
been removed): no more compilation step, pure python source code (no
more "CherryClass")

Here is a sample Hello, World in CherryPy-2:

# from cherrypy import cpg
# class HelloWorld:
# @cpg.expose
# def index(self):
# return "Hello world!"
# cpg.root = HelloWorld()
# cpg.server.start()

Main properties:
- this code starts a multi-threaded HTTP server that dispatches
requests to methods
- requests like "http://domain/dir/page?arg1=val1&arg2=val2" are
mapped to "dir.page(arg1='val1', arg2='val2')"
- requests are mapped to an object tree that is "mounted" on cpg.root
(for instance: "cpg.root.user", "cpg.root.user.remi", ...)
- method must be explicitely exposed with a decorator "@cpg.expose"
(or "index.exposed = True" for Python-2.3)
- methods can return a generator instead of a string (useful when
generating big pages)

Here is a non-exhaustive list of CherryPy-2 features:
multi-threaded HTTP server, XML-RPC server, sessions, form handling,
authentication, unicode support, gzip-compression, virtual hosting,
WSGI adapter (experimental)

The design of CherryPy-2 allows to easily write/use pluggable "filters"
or "modules":
- filters perform operations on the request/response such as
gzip-compression or string encoding
- modules are web applications (like a blog or a web forum) than can
be easily "mounted" anywhere you want in your website

CherryPy-2 is already used in production by several sites and is
supported by an active community.


Remi.

http://www.cherrypy.org

 

[andybak]

I'm a great believer that avoiding query strings in URL's is good
practise ( http://www.holloway.co.nz/book/9 for good arguments why).

How tricky is it to remap URL's to query strings in cherryPy? Also how
much does it complicate matters to run cherryPy under an existing
webserver? Is any functionality lost?

 

[remi]

I'm a great believer that avoiding query strings in URL's is good

practise ( http://www.holloway.co.nz/book/9 for good arguments why).

CherryPy also supports that out of the box:

class Book:
def default(self, categoryName, bookId):
....
cpg.root.book = Book()

If you go to "http://domain/book/science/9", CherryPy will call
book.default('science', '9')

Also how
much does it complicate matters to run cherryPy under an existing
webserver? Is any functionality lost?

Well, you can easily run CherryPy behind Apache (see
http://trac.cherrypy.org/cgi-bin/trac.cgi/wiki/BehindApache).
Since CherryPy provides a WSGI interface (although it's still
experimental), you can also run your CherryPy app with any
WSGI-compatible HTTP server (although I don't really see any advantage
to doing this).

Remi

 

[Ian Bicking]

Well, you can easily run CherryPy behind Apache (see
http://trac.cherrypy.org/cgi-bin/trac.cgi/wiki/BehindApache).
Since CherryPy provides a WSGI interface (although it's still
experimental), you can also run your CherryPy app with any
WSGI-compatible HTTP server (although I don't really see any advantage
to doing this).

In the future when more WSGI environments are deployed, I think the
benefits will be nice. For instance, under WSGIKit
(http://svn.colorstudy.com/trunk/WSGIKit) you should be able to create a
file:

# cherry_app.py:

from cherrypy import cpg, wsgiapp
from my_cherry_app import root_instance
cpg.root = root_instance
wsgiapp.init()
# This variable name is automatically picked up:
application = wsgiapp.wsgiApp

Then your application would be available under cherry_app/ (wherever you
happened to put that file in the URL space). Note that WSGIKit isn't a
server itself, just a set of middleware that delegates to different
applications.

It occurs to me that it would be considerably cleaner if it looked more
like this:

from cherrypy import wsgiapp
from my_cherry_app import root_instance
application = wsgiapp.Application(my_cheery_app)

Otherwise you can only run one CherryPy application in a process...?
That would be very limiting.

Anyway, the idea is you can deploy a CherryPy-based application fairly
easily alongside other WSGI Python web applications. The particulars
still need some work -- I don't like the little Python file used to put
the pieces together -- but I think it's a good direction.