The willStart function is called before rendering, and, more importantly, returns a deferred object that must be resolved before rendering starts. So, in a case like ours, where we need to run an asynchronous action before rending can occur, this is the right function to do it.

When dealing with data access, we rely on the _rpc function provided by the ServicesMixin class explained earlier. This function allows you to call any public function on some model such as search or read, or in this case, search_read. You could also have required web.rpc and have called the query function on it; this is what _rpc does under the hood.

In any case, we’ll have to collect the results asynchronously in our success handler. This will set up the internal data structure user_list the same way we did earlier in the hard-coded version, which is great, because this way, we don’t have to change anything else.

Note that we request the display_name field here instead of name, because we can be sure that every model has a display_name field, whereas that’s not guaranteed with the name field. Then, we just assign the name property the same value as display_name; again, this is in order to not have to change the existing code more than necessary. Do this too instead of a lot of overrides if you just need to divert display to another field or something similar. For details about the display_name field, refer to the Defining the Model representation and order recipe in Chapter 5, Application Models.

The end of the handler contains the crucial part, resolving the deferred object we created earlier. This, in combination with returning the deferred object wrapped along with super’s result in a new deferred object created by the jQuery.when call, causes rendering to only happen after the values are fetched and whatever asynchronous action super was busy with finished too. This way, you can be sure in the template code that widget.user_list is accessible and contains the values we need.