I've read around and found this answered question about a problem relating to this but what I really want to know is how to implement this structure and how many handler classes I need:
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
I was thinking having 2,5,7 mapped to a single handler routed to /items/[0-9]+ and having 3 new handlers for the items, items/new and /items/[0-9]+/edit. The downside is that it felt like a sub-optimal solution to have 4 handlers for a single resource.
I'm terribly new to proper routing/handling/webapps but I at least give it a good read before I start on something. Are there any better suggestions for how many/how you route your handlers?
Well, it is largely stylistic. Each request handler in this situation represents the removal of an if statement from one of your methods. I think it can be clearer to limit the number of RequestHandlers. The clearest results I think can be achieved with one handler and three routes.
I've also thrown away your item 3. Because it is a duplication of item 6. If having an 'items/new' url is really important then we could put it back in. Though I think at that point you would need another handler class for clarity.
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
Then the actual application could be created like this:
tornado.web.application([ (r'/items$', ItemHandler), (r'/items/(\d+$)', ItemHandler), (r'/items/(\d+)/(edit)$', ItemHandler), ])
If you want the '/items/new' url then I would probably suggest putting that in a separate handler because it would otherwise make the logic overly complex.
