Ann: CherryPy-2.0-beta released

Discussion in 'Python' started by remi@cherrypy.org, Jan 3, 2005.

  1. Guest

    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
     
    , Jan 3, 2005
    #1
    1. Advertising

  2. Guest

    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?
     
    , Jan 3, 2005
    #2
    1. Advertising

  3. Guest

    > 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
     
    , Jan 3, 2005
    #3
  4. Ian Bicking Guest

    wrote:
    > 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.

    --
    Ian Bicking / / http://blog.ianbicking.org
     
    Ian Bicking, Jan 3, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Remi Delon

    [ANN] CherryPy-0.10 released

    Remi Delon, Apr 27, 2004, in forum: Python
    Replies:
    0
    Views:
    245
    Remi Delon
    Apr 27, 2004
  2. mep
    Replies:
    2
    Views:
    623
    Remi Delon
    Mar 9, 2005
  3. Replies:
    0
    Views:
    274
  4. Replies:
    1
    Views:
    286
    Damjan
    Jul 15, 2005
  5. Replies:
    0
    Views:
    295
Loading...

Share This Page