As a web developer comming from Ruby on Rails, the "flexibility" of the handlers organization in Tornado is really painful. So I decide to organize the handlers in a Rails way.
By default, in Tornado, the actions of a handler are exactly the http verb: GET, POST, PATCH, DELETE. So when I think about how to write a handler, I have to think in the protocol layer.
For example, building a websites of books. The books list page and book detail page both use the same http verb GET, but they have totally different logic in the backend. If we organize the handler in http verb, then the handler goese like this:
class BooksHandler(RequestHandler):
def get(self, id=None):
if id is not None:
# render book list page
else:
# render book detail of id
Wouldn't that be great if we could just seperate the 2 unrelated pieces of code into 2 methods, like the following:
class BooksHandler(RequestHandler):
def index(self):
# render book list page
def show(self, id):
# render book detail of id
And that is the main goal of the refactoring, to organize the handlers in a Resource way instead of Protocol way.
Luckly Ruby on Rails already done this before and have been proved to be practisable even in large projects. So I'm just gonna copy the resource abstraction of Rails, that is:
- A Handler is for manumating one resource.
- A Handler can have at most 7 actions. The following table shows what the action should do and how does a http request reach them.
| HTTP Verb | Path | Handler#Action | Used for |
|---|---|---|---|
| GET | /photos | photos#index | display a list of all photos |
| GET | /photos/new | photos#new | return an HTML form for creating a new photo |
| POST | /photos | photos#create | create a new photo |
| GET | /photos/:id | photos#show | display a specific photo |
| GET | /photos/:id/edit | photos#edit | return an HTML form for editing a photo |
| PATCH/PUT | /photos/:id | photos#update | update a specific photo |
| DELETE | /photos/:id | photos#destroy | delete a specific photo |
Then What about login? I don't see any resources in that action.
Everything can be resources. For login/logout, it's actually create a session and destroy a session.
Now if we organizing our handlers in this way, there is no need for us to write the router's url matcher manully, a handler should populate the routes by itself, like these:
class BooksHandler(RequestHandler):
def index(self):
# render book list page
def show(self, id):
# render book detail of id
app = tornado.web.Application([
# no more manully set regex
*BooksHandler.routes()
])
app.listen(8888)
tornado.ioloop.IOLoop.current().start()
Now, it should be good to visit the 2 url:
curl http://localhost:8888/books
curl http://localhost:8888/books/1
I have already implemented this at https://github.com/louis-she/tornado-resource-handler. This can be directly used in existed projects, just try to write new handler in resource way, it will not broke the existing handlers.
Have fun with abstracting Resources.
Top comments (0)