Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>CherryPy deliberately doesn't require you to subclass from a framework-provided base class so that you are free to design your own inheritance mechanism, or, more importantly, use none at all. You are certainly free to define your own base class and inherit from it; in this way, you can standardize handler construction and configuration via the <code>__init__</code> method of your class, and via class-level variables and methods.</p> <p>However, the preferred approach is different. For most web applications, you don't really want to vary the actual construction logic of your handlers, nor do you care much about class-level variables or methods; instead, you want reusable variables and methods per URI or per subtree of URI's or per site, not per class. You tend to vary one set of handlers from another set more by instance configuration (handler metadata) and instance methods (handler logic). Traditional class-based inheritance can do this, but it's a bit of a blunt instrument for that kind of customization.</p> <p>CherryPy, therefore, is designed to provide this sort of per-resource-set customization that class-based inheritance doesn't do well. It provides this through 1) the design of its configuration system, which allows you to bind <em>metadata</em> to a single URI, a subtree of URI's, a subtree of handlers, or a whole site with the same syntax (see <a href="http://docs.cherrypy.org/dev/intro/concepts/config.html" rel="noreferrer">http://docs.cherrypy.org/dev/intro/concepts/config.html</a> for an overview), and 2) the hooks and tools system, which allows you to bind <em>logic</em> to a single URI, a subtree of URI's, a subtree of handlers, or a whole site. See <a href="http://docs.cherrypy.org/dev/intro/concepts/tools.html" rel="noreferrer">http://docs.cherrypy.org/dev/intro/concepts/tools.html</a></p> <p>So, practically: do use normal attributes on <code>cherrypy.root</code> to build your tree of handlers:</p> <pre><code>def make_app(): root = Root() root.foo = Foo() root.bars = BarCollection() return root </code></pre> <p>However, don't make Root, Foo and Bar inherit from a common base class. Instead, write independent Tools to do things like "infer templates". That is, instead of:</p> <pre><code>from cherrypy import expose class Foo(MyAppBase): @expose() def index(self, a, b, c): ... root.foo = Foo(template='foo.html') </code></pre> <p>write:</p> <pre><code>from cherrypy import expose, tools class Foo(object): @tools.render(template='foo.html') @expose() def index(self, a, b, c): ... root.foo = Foo() </code></pre> <p>...where 'tools.render' is a CherryPy Tool you have written to look up and apply the given template. This approach will allow you to override the arguments to the Tool in your config file and avoid having to repackage or patch your code:</p> <pre><code>[/foo/] tools.render.template = 'foo2.html' </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload