CSC/ECE 517 Fall 2014/ch1a 3 cp

From Expertiza_Wiki
Jump to navigation Jump to search

CherryPy

CherryPy Logo<ref>http://www.cherrypy.org/images/cherrypy.png</ref>
CherryPy Logo<ref>http://www.cherrypy.org/images/cherrypy.png</ref>
Name CherryPy
Category Open Source Software
Type Web Application Framework
Developer(s) CherryPyTeam
License BSD
Latest Stable Version 3.3.0 / April 16, 2014
Written in Python

Overview

CherryPy is an Object-Oriented Web Application Framework meant to be Python-like (sparse and clean code).
It is important to note that it is not a complete stack such as Ruby on Rails, Laravel, or Django. Complete stack web frameworks offer frontend utilities and storage communications along with other abilities. These aspects that make the frameworks so powerful, however, also contribute to the framework being bulky making development of small web applications such as blogs a bit cumbersome. CherryPy instead prefers to defer decisions such as storage management and interface utilities to the developer <ref>http://docs.cherrypy.org/en/latest/intro.html</ref>

History

The CherryPy project v0.1 was founded and release by Remi Delon in Jul 2002<ref>http://freecode.com/projects/cherrypy/</ref> on FreeCode. Version v2.0 released in May 2005 and was moved to BitBucket from v2.1 onwards. Remi Delon is now works full time on WebFaction (which he also founded in 2003) although he is still recognized as project leader for CherryPy. Finally in Dec 2006 v3.0 came out with much of the original code rewritten under Robert Brewer as the lead developer.<ref>https://bitbucket.org/cherrypy/cherrypy/wiki/CherryPyTeam</ref><ref>https://docs.google.com/presentation/d/1NOGM5w1yu6dnXyEyYC4r6ZDuRgii4YaqlkrrlxfbnzM/edit?pli=1#slide=id.g178c5c5e9_032</ref>

Major Changes
v2.0 Unpythonic features removed. There is no longer a compilation step; it is pure Python source code (no more "CherryClass"). <ref>http://freecode.com/projects/cherrypy/releases</ref>
v2.1 New HTTP servers, and WSGI support. New Profiler module. New config system added<ref>https://bitbucket.org/cherrypy/cherrypy/wiki/WhatsNewIn21</ref>
v2.2 Custom WSGI server support<ref>https://bitbucket.org/cherrypy/cherrypy/wiki/WhatsNewIn22</ref>
v3.0 Tools support. New Logger. Multiple HTTP server support. Considerable speedup.<ref>https://bitbucket.org/cherrypy/cherrypy/wiki/WhatsNewIn30</ref>
v3.1 Plugins support. cherryd script.<ref>https://bitbucket.org/cherrypy/cherrypy/wiki/WhatsNewIn31</ref>
v3.2 Python 3 support.<ref>https://bitbucket.org/cherrypy/cherrypy/wiki/WhatsNewIn32</ref>

Installation

Overview

Because CherryPy is nothing more than a Python library, it needs a Python environment (Python 2.3 through to 3.4) and can also run on various implementations of Python including IronPython for .NET and Jython for Java.<ref>http://docs.cherrypy.org/en/latest/install.html</ref>

Requirements

CherryPy requires a Python version between 2.3 and 3.4 inclusively. Certain features require packages but none are mandatory for installation.<ref>http://docs.cherrypy.org/en/latest/install.html</ref>


Installing

CherryPy can be installed through common Python package managers with the following commands:<ref>http://docs.cherrypy.org/en/latest/install.html</ref>

Install (choose on of the following commands appropriately):

   $ easy_install cherrypy
   $ pip install cherrypy
   $ yum install python-cherrypy
   $ apt-get install python python-dev

Install via yum

CherryPy is provided by the fedora base repository. In Fedora (and other RPM based Linux distributions, such as CentOS and Red Hat Enterprise Linux):

   $ yum install python-cherrypy

Install via apt-get

CherryPy is also provided in the Ubuntu base repository. In Ubuntu (and other Debian-based Linux distributions such as Debian and Linux Mint):

   $ apt-get install python python-dev

Installation from source

The source code is hosted on BitBucket and requires Mercurial to pull and install from the site itself.

   $ hg clone https://bitbucket.org/cherrypy/cherrypy
   $ cd cherrypy
   $ python setup.py install

Alternatively, the source can be manually downloaded from here in a tarball.

   $ tar -xvf CherryPy-#.#.#.tar.gz
   $ cd CherryPy-#.#.#
   $ python setup.py install

Install for Windows

  • If you are using Windows, install Linux and follow any of the a forementioned methods.
  • If you absolutely must use windows, you can download the .exe file to install CherryPy from here.

Interface

CherryPy is meant to be pythonic, meaning that development time is meant to be minimized and code is meant to be sparse and clean <ref>http://docs.cherrypy.org/en/latest/intro.html</ref>

Basic Example

Lets look at a hello world example<ref>https://cherrypy.readthedocs.org/en/3.2.6/concepts/basics.html</ref><ref>http://stackoverflow.com/questions/419163/what-does-if-name-main-do</ref>

#Use the cherrypy python library
import cherrypy

#Hello World project
class HelloWorld(object):

#   index page
    def index(self):
#       Return the page contents
        return “Hello World!”

#   Allow the page to be visible
    index.exposed = True

#designates this module as main
if __name__ == ‘__main__’:

#   instantiates app and starts server
    cherrypy.quickstart(HelloWorld())

The above script sets up a basic Hello World application, by defining the index page (http://localhost:8080/) as an object that returns the string “Hello World!”. The page is exposed, meaning that the method can be called to answer a RESTful request. Otherwise, the method is internal only. This is similar to making a method public in Java. <ref>http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html</ref>

Routing, Parameters, and Exposure

Routing is the act of finding the appropriate code to handle a request. CherryPy uses a dispatcher to perform most of these, but premade dispatchers exist to handle more sophisticated handling of request. The most common is a page handler (the name of the object). Parameters can be passed into the handler via http query strings. These strings are appended to the URL of a site after a "?". Exposure is just the way CherryPy prevents access to objects from the users. Without the exposed attribute set to true, an object won't be accessible to the user.

#import python library
import cherrypy

#More Routes application
class MoreRoutes(object):

#   Method decorator for index and equates to index.exposed = True
    @cherrypy.expose
    def index(self):
        return "Hello world!"

#   http://localhost:8080/route1
    def route1(self, id=”charles”):
#       http://localhost:8080/route1?id=somestring
        return “Your name is ” + id

#   Params passed as a GET request.
#   Default string is “charles”
    route1.exposed = True

#   No explicit indication of exposure so calling this route will generate a 404 error
    def route2(self):
        return “Still another one”

if __name__ == '__main__':
    cherrypy.quickstart(MoreRoutes())

The above shows how multiple routes are handled from the Hello World application and the expose decorator. Since route2 is not exposed, the user can not access it and will be shown a 404 HTTP status code (Not Found error).

Multiple Applications

import cherrypy
#blog module
class Blog(object):
    ...<blog code>...
#forum module
class Forum(object):
    ...<forum code>...
#”main” method
if __name__ == '__main__':
#designates the blog to be under /blog route
    cherrypy.tree.mount(Blog(), ‘/blog’, “blog.conf”)
#designates the forum to be under /forum route
    cherrypy.tree.mount(Forum(), ‘/forum’, “forum.conf”)

<ref>http://docs.cherrypy.org/en/latest/basics.html#multiple-applications</ref>

In the above example, the blog would be found under /blog in the URL, wheras the forum will be mounted at /forum in the application tree. The XXX.conf files are configuration files, which are dictionaries containing string keys and polymorphic values and can be used to set attributes on the engine, server, request, response, and log objects. <ref>https://cherrypy.readthedocs.org/en/3.2.6/concepts/config.html</ref>

Database Support

CherryPy offers multiple database integration possibilities including

Unfortunately, unlike Ruby on Rails, CherryPy does not have a sophisticated Active Record Pattern based class for database abstraction, and the database connection has to be established manually. The queries are constructed as static SQL strings with values concatenated during function calls.

Here is an example of how it would look like<ref>http://cherrypy.readthedocs.org/en/latest/tutorials.html#tutorial-9-data-is-all-my-life</ref>


# import the Handles
import MySQLdb
import cherrypy

# defining the connection function
def connect(thread_index):
#   Create a connection and store it in the current thread
    cherrypy.thread_data.db = MySQLdb.connect('host', 'user', 'password', 'dbname')

# tell cherrypy to  call connect function for each thread
cherrypy.engine.subscribe('start_thread', connect)

# example query function
@cherrypy.expose
def count(val)
#   fetching instance of db connection
    c = cherrypy.thread_data.db.cursor()
#   executing query
    c.execute( 'select count(‘ + val + ’) from table' )
#   fetching results from db
    res = c.fetchone()
#   releasing instance of the connection
    c.close()
#   returning the count value
    return res

RESTful CherryPy

REST (Representational State Transfer) is an abstraction of the architectural elements within a distributed hypermedia system. It ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application. <ref>http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm</ref>
In othe words, REST is defined by four interface constraints: identification of resources, manipulation of resources through representations, self-descriptive messages, and hypermedia as the engine of application state.<ref>https://cherrypy.readthedocs.org/en/3.2.6/progguide/REST.html</ref>

Identification of Resources

Since Cherrypy is an HTTP service provider, resources are referenced by HTTP URIs (Uniform Resource Identifiers), which consist of a scheme, hierarchical identitfier, query, and fragment.<ref>https://cherrypy.readthedocs.org/en/3.3.0/progguide/REST.html#implementing-rest-in-cherrypy</ref>

  • Scheme: in http, the scheme is always http or https.
  • Hierarchical Identifier: consists of an authority and a path (host/port and a path similar to the system file path but not the actual path). The path is mapped to Python Objects via a dispatch mechanism.

Manipulation of Resources Through Representations

The standard HTTP methods are as follows<ref>https://cherrypy.readthedocs.org/en/3.3.0/progguide/REST.html#manipulation-of-resources-through-representations</ref>

  • GET retrieves the state of a specific resource
  • PUT creates or replaces the state of a specific resource
  • POST passes information to a resource to use as it sees fit
  • DELETE removes resources

Self-Descriptive Messages

REST requires messages to be self-descriptive, meaning everything about a message is within the message itself. Such information can be found in the method headers or the definitions of the message’s media type. cherrypy.request.headers and cherrypy.response.headers are used to get this information. Custom-Types are allowed as well.<ref>https://cherrypy.readthedocs.org/en/3.3.0/progguide/REST.html#self-descriptive-messages</ref>

Hypermedia as the Engine of the Application State

Since REST is stateless and the state is maintained by the application in question, sessions are not maintained by REST, so, by association, CherryPy does not enable sessions by default. However, the REST server helps clients maintain a meaningful state through meaningful URIs<ref>https://cherrypy.readthedocs.org/en/3.3.0/progguide/REST.html#hypermedia-as-the-engine-of-application-state</ref>

Crash Course

Development

Create an application. Application requirements:

  • The module needs to define a __main__
  • cherrypy.quickstart(<Application Name>()) for hosting a single application. For example: cherrypy.quickstart(Blog())
  • cherrypy.tree.mount(<Application Name>(), ‘/<hosting path segment>’, <configuration>) for hosting multiple applications. For example: cherrypy.tree.mount(Blog(), ‘/blog’, blog_conf)
  • All parts the users will see must be exposed with either the decorator @cherrypy.expose or attribues exposed = True or route.exposed = True.
import cherrypy
class HelloWorld(object):
    def index(self):
        return “Hello World!”
    index.exposed = True
if __name__ == ‘__main__’:
    cherrypy.quickstart(HelloWorld())

Deployment

The application can be run as a python script in the Python interpreter.

   $ python <app file>.py

It will hosted at http://127.0.0.1:8080/ It can also be run as a daemon process with

   $cherryd -c <config file> -d -p <PID file>

Testing

CherryPy provides a helper class for testing. The feature of the framework is that test are run against a running cherrypy server and testing small cmponents without actually starting the server is not natively suported.

Lets look at an example<ref>http://cherrypy.readthedocs.org/en/latest/advanced.html#testing-your-application</ref>

#importing cherrypy library
import cherrypy

#importing the helper class
from cherrypy.test import helper

#creating a simple test class
class SimpleCPTest(helper.CPWebCase):

#   function to start the cherrypy server
    def setup_server():

#       root class of application  to be tested
        class Root(object):

#           the expose method which we are trying to test
#           this method will respond to localhost/echo and actually echo the argument sent to it
            @cherrypy.expose
            def echo(self, message):
                return message

#       settingup the root class to be created on server start
        cherrypy.tree.mount(Root())

#   grabbing the decorator for starting the server
    setup_server = staticmethod(setup_server)

#   This is the actual test code
    def test_message_should_be_returned_as_is(self):

#       sending arguments to the echo method via html request
        self.getPage("/echo?message=Hello%20world")

#       chechink if server accepted our request
        self.assertStatus('200 OK')

#       cheching response from server
        self.assertHeader('Content-Type', 'text/html;charset=utf-8')

#       checking if the was an "Hello World" in the response from server
        self.assertBody('Hello world')

Extensions

CherryPy provides a flexible open framework. Similar to RubyGems in Ruby on Rails which add a range of functionality to the framework CherryPy also supports plugins in the the following forms

Server Wide Functions (Plugins)

This type of extension is typically used to provide the application server itself with additional functionality. Such functions are executed with respect to events in the server even when there is no client request processing taking place.<ref>http://docs.cherrypy.org/en/latest/extend.html#id13</ref>
Typical use case involve

  • Background Tasks (Tasks which involve server mentainance, data management etc. which are independent of user requests)
  • External Connections (For establishing and maintaining threaded connections to external database or other servers)
  • Delayed/Queued Processing (Cases when certain tasks are required by the user request which take a long time process and the HTTP response should not be blocked.)

These function utilize the Publish-Subscribe Framework implementation of CherryPy. Each function subscribes to one or more events on the bus which are published by the CherryPy engine.
The database connection is a good example of such a function

# import the Handles
import MySQLdb
import cherrypy
# defining the connection function
def connect(thread_index): 
    # Create a connection and store it in the current thread 
    cherrypy.thread_data.db = MySQLdb.connect('host', 'user', 'password', 'dbname')

# tell cherrypy to  call connect function for each thread
cherrypy.engine.subscribe('start_thread', connect)

Here the function connect subscribes to the start_thread channel. An event is published on the start_thread channel whenever a server thread is started. Here engine is the central bus of the CherryPy server.
Similarly it is also possible to create new channels and even buses themselves.

Per-Request Functions (Tools)

This type of extension is typically used to insert functionality between stages of request processing. Also known as Tools these are simple call-back functions registered with a Hook Point. Hook Points are predefined stages of request processing. CherryPy provides a Default ToolBox containing many tools. Users have the freedom to create their own tools and add them to the default toolbox or create a new one.<ref>http://docs.cherrypy.org/en/latest/extend.html#per-request-functions</ref>
An example for creating a tool

# defining the function to be called
def my_tool():
    # put tool functunality here
    print (“Super Amazing Tool”);

# creating the decorator for the tool
# specifying the hook point and function to be called
cherrypy.tools.mytool = cherrypy.Tool(‘on_end_request’, my_tool())

#Sample Usage

class Root(object):
@cherrypy.expose()
@cherrypy.tools.mytool()
def index()
    return “Hello World”

Watch It In Action

CherryPy is used as a building block for Hulu<ref>http://tech.hulu.com/blog/2013/03/13/python-and-hulu</ref> and Netflix<ref>http://techblog.netflix.com/2013/03/python-at-netflix.html</ref>

Further Reading

PowerPoint Presentation


References

<references/>