5

私はチェリーピーアプリを書いていますが、ハンドラーと大規模なアプリケーションのコードを構築するための最良の方法は何だろうと思っていましたか?

割り当てはcherrypy.rootから簡単だと思いますが、ハンドラーを作成して割り当てるためのプラクティスは何ですか?

(私の混乱を証明させてください!) 私が最初に考えたのは、現在の URL またはクラスとメソッドの組み合わせに基づいて実行するテンプレートを推論する標準ハンドラー クラスを作成することです。次に、そのハンドラーの 1 つのインスタンスをパスに複数回割り当てて、ページを作成します。ただし、再帰参照が正しく機能しないため、これが機能しているとは思いません。

ですから、私自身のソース コードがどのように見えるべきかについて既に空白を描いているという事実を考えると、いくつかの指針と例が欲しいです!

明確にするために、いくつかの詳細な質問をしてください。チュートリアルの素材はたくさんありますが、表面をなぞっただけの傾向があります。

4

2 に答える 2

10

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 __init__ method of your class, and via class-level variables and methods.

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.

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 metadata to a single URI, a subtree of URI's, a subtree of handlers, or a whole site with the same syntax (see http://docs.cherrypy.org/dev/intro/concepts/config.html for an overview), and 2) the hooks and tools system, which allows you to bind logic to a single URI, a subtree of URI's, a subtree of handlers, or a whole site. See http://docs.cherrypy.org/dev/intro/concepts/tools.html

So, practically: do use normal attributes on cherrypy.root to build your tree of handlers:

def make_app():
    root = Root()
    root.foo = Foo()
    root.bars = BarCollection()
    return root

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:

from cherrypy import expose

class Foo(MyAppBase):
    @expose()
    def index(self, a, b, c):
        ...

root.foo = Foo(template='foo.html')

write:

from cherrypy import expose, tools

class Foo(object):
    @tools.render(template='foo.html')
    @expose()
    def index(self, a, b, c):
        ...

root.foo = Foo()

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

[/foo/]
tools.render.template = 'foo2.html'
于 2010-04-19T17:41:50.673 に答える
5

この質問は非常に主観的なものですが、試してみます。

  • まず、データベースとデータコードを常にWebコードとは別にしてください。私がしていることは、DB/フォルダ内にそれぞれ1つのクラスを持つ多数の小さなファイルがあり、それらはすべて1つのファイルに結合されていBase.pyます。 

    ウェブ/
    Base.py-他のクラスを含むメインの「ベース」クラス
              Webファイル、でWebサーバーを起動します__init__
    Users.py-一般的に「DB/Users.py」のメソッドを含むクラス
               戻る前に権限などをチェックします（
               ただし、後でDBレベルのセキュリティを追加したい）
    ..。
DB /
    Base.py-メインのベースDBクラスで、他のDBクラスが含まれます。作成します
              新しいSQLAlchemy/その他のインスタンスとデータベーススキーマを作成する場合
              彼らはそうではありません。データベース全体の方法を持つためにお金を払うかもしれません
              ここでは、接続などを1か所で作成し続けることができます
              後でデータベースを変更することを決定する
    Users.py-ユーザー/パスワードなどのDBストレージクラスファイル
    ..。
テンプレート/
    （HTMLテンプレートはここにあります）
静的/
    （静的画像/ CSS / javascriptなどはここにあります）
    __init__.pyもちろん、Pythonがサブディレクトリでモジュールを見つけることができるように、各モジュールディレクトリにあることを 忘れないでください

  • 私の意見では、コードを構造化するためにどのメソッドを使用するかは必ずしも重要ではありませんが、一貫性があります。私はすべての慣習を使用する理由を記載した文書を作成し、それが理にかなっているところまでそれらをフォローしようとしますが、いつものように、 Pythonスタイルのドキュメントa foolish consistency is the hobgoblin of small mindsを引用しています:-)

  • ストレート関数ではなく、クラスを使用するようにしてください。小さなプロジェクトでは問題にならないかもしれませんが、重要なことは困難になる可能性があります。特定の目的を持つ多くのファイルを持ち、複数のファイルを用意することが理にかなっている場合を除いて、1つのファイルに1つのクラスだけを含めることが私の好みです。

  • これはおそらく物議を醸すものです-私は通常、クラスClassに名前を付け、モジュール名で参照します。Base.pyの例を示します。
    import Users
class Base(Users.Class):
    def __init__(self):
        Users.Class.__init__(self)
    これは、インポート時に他のモジュールが相互に参照する場合の問題を減らすのに役立ちます。from Users import Users競合する場合Users.pyはfrom Base import x、常にモジュール名で参照します。これは個人的な好みですが、やりたいことをしてください:-P

うまくいけば、この投稿からアイデアを得る必要があります。

于 2010-04-19T04:11:37.870 に答える