It's nice to be able to show content, but it's better to show content as a result of some user input. This recipe will demonstrate the different ways to receive this input and react to it. As in the previous recipes, we'll make use of the library.book model.
First, we'll add a route that expects a traditional parameter with a book's ID to show some details about it. Then, we'll do the same, but we'll incorporate our parameter into the path itself:
- Add a path that expects a book's ID as parameter:
@http.route('/my_module/book_details', type='http', auth='none') def book_details(self, book_id): record = request.env['library.book'] .sudo().browse(int(book_id)) return u'<html><body><h1>%s</h1>Authors: %s' % ( record.name, u', '.join( record.author_ids.mapped('name')) or 'none', ) - Add a path where we can pass the book's ID in the path:
@http.route("/my_module/book_details/<model( 'library.book'):book>", type='http', auth='none') def book_details_in_path(self, book): return self.book_details(book.id)
If you point your browser to /my_module/book_details?book_id=1, you should see a detail page of the book with ID 1. If this doesn't exist, you'll receive an error page.
The second handler allows you to go to /my_module/book_details/1 and view the same page.
By default, Odoo (actually werkzeug) intermingles with GET and POST parameters and passes them as keyword argument to your handler. So by simply declaring your function as expecting a parameter called book_id, you introduce this parameter as either GET (the parameter in the URL) or POST (usually passed by forms with your handler as action) parameter. Given that we didn't add a default value for this parameter, the runtime will raise an error if you try to access this path without setting the parameter.
The second example makes use of the fact that in a werkzeug environment, most paths are virtual anyway. So we can simply define our path as containing some input. In this case, we say we expect the ID of a library.book as the last component of the path. The name after the colon is the name of a keyword argument. Our function will be called, with this parameter passed as keyword argument. Here, Odoo takes care of looking up this ID and delivering a browse record, which of course only works if the user accessing this path has appropriate permissions. Given that book is a browse record, we can simply recycle the first example's function by passing book.id as parameter book_id to give out the same content.
Defining parameters within the path is a functionality delivered by werkzeug, which is called converters. The model converter is added by Odoo, which also defines the converter models, that accepts a comma separated list of IDs and passes a record set containing those IDs to your handler.
The beauty of converters is that the runtime coerces the parameters to the expected type, while you're on your own with normal keyword parameters. These are delivered as strings, and you have to take care of the necessary type conversions yourself, as seen in the first example.
Built-in werkzeug converters include int, float, and string, but also more intricate ones such as path, any, or uuid. You can look up their semantics at http://werkzeug.pocoo.org/docs/0.11/routing/#builtin-converters.
Odoo's custom converters are defined in ir_http.py in the base module and registered in the _get_converters method of ir.http. As an exercise, you can create your own converter that allows you to visit the /my_module/book_details/Odoo+cookbook page to receive the details of this book (if you added it to your library before). This converter's implementation is included in the example code for this recipe.