12

私は周りを読んで、これに関連する問題に関するこの回答付きの質問を見つけましたが、本当に知りたいのは、この構造を実装する方法と、必要なハンドラー クラスの数です。

1  GET    /items        #=> index
2  GET    /items/1      #=> show
3  GET    /items/new    #=> new
4  GET    /items/1/edit #=> edit
5  PUT    /items/1      #=> update
6  POST   /items        #=> create
7  DELETE /items/1      #=> destroy

/items/[0-9]+ にルーティングされる単一のハンドラーに 2,5,7 をマップし、items/new と /items/[0-9]+/edit の 3 つの新しいハンドラーを持つことを考えていました。欠点は、1 つのリソースに対して 4 つのハンドラーを使用するのは最適ではないソリューションのように感じられることです。

私は適切なルーティング/処理/webapps に非常に慣れていませんが、何かを始める前に少なくともよく読んでいます。ハンドラーをいくつ/どのようにルーティングするかについて、より良い提案はありますか?

4

1 に答える 1

19

まあ、それは主にスタイルです。この状況の各リクエスト ハンドラーは、メソッドの 1 つから if ステートメントを削除したことを表します。RequestHandlers の数を制限する方が明確になると思います。最も明確な結果は、1 つのハンドラーと 3 つのルートで達成できると思います。

アイテム 3 も破棄しました。これはアイテム 6 と重複しているためです。「items/new」URL が本当に重要な場合は、元に戻すことができます。ただし、その時点で別のハンドラーが必要になると思いますが、明確にするためのクラス。

class ItemHandler(tornado.web.RequestHandler):

    def get(self, item_id=None, edit=False):
        if item_id:
            # get item from db
            if edit:
                new_data_from_query_string = self.get_argument('item_data')
                # do edit, save item
            # return item
        else:
            # return index

    def put(self, item_id):
        data = self.get_argument('item_data')
        # do your update for item

    def post(self):
        data = self.get_argument('item_data')
        # do your item creation

    def delete(self, item_id):
        # do your deletion for item_id

次に、実際のアプリケーションは次のように作成できます。

tornado.web.application([
    (r'/items$', ItemHandler),
    (r'/items/(\d+$)', ItemHandler),
    (r'/items/(\d+)/(edit)$', ItemHandler),
])

「/items/new」の URL が必要な場合は、それを別のハンドラーに入れることをお勧めします。そうしないと、ロジックが複雑になりすぎるからです。

于 2012-09-12T13:13:04.643 に答える