Window Actions

Window actions are the main way of interacting with Odoo Models.

It opens up a window, and has a bunch of different 'Views' or 'View Types'

These are quite well documented in the Official Odoo Docs.

What is not so well documented, is how do we create custom views.

Let's look at the different components of a View Type first, then see how we can fit them together.

Arch

Each view has an 'Architecture'. These are basically parameters which control how the view is laid out.

For example, in the tree view (i.e. list of models), we have to define which fields will appear and be visible in the table.

For the form view, we have to define the order of fields and how they will be displayed, how they are grouped, if we want them on separate pages, if we want to include any other text labels or other items in the form etc.

So the architecture of the view makes the views flexible and customisable.

Arch Parser

Not surprisingly, the arch is defined in an XML template. It is user defined. So as they writer of a custom view, you have to be able to accept any arch that the user supplies.

The arch has to conform to your schema, but it basically allows the user to inject the data they want into the architecture you specify.

So the tree view arch takes a list of fields. It takes that list, and uses each item as a column in the table.

When you write the arch parser, you have to think about what settings you will allow users to configure and how that will impact the final result.

Model

The model is a JS class that is responsible for loading the data. It will use any filters (called domain) to fetch the necessary data from the server and pass it into the controller.

For example the tree view will paginate the data, and also apply filters.

Renderer

This is another JS class that is responsible for actually rendering the template. So the renderer has an XML template attached, that is basically the HMTL that will get rendered to the screen. This is pretty much just an OWL component.

It will however also utilise the results of the parsed arch (the arch info). So again, for the tree view example this would probably end up being an array of fields.

The renderer could then inspect those fields, make the necessary number of columns, insert the correct headings, then while it is iterating over the list, place the correct fields into the correct columns.

Controller

I'm not 100% sure what this is for. But from looking at the source code, it seems to me that it defines how we integrate our view into the main layout of the Odoo Web Client.

So you can add buttons or other items outside the main area that is rendered for the window action, and also define where the renderer will render. I.e. where we will see the data.

In other words, you could force your renderer to live inside the main window, or you could wrap it in some other HTML elements, or put certain components into the headers or other places inside the Web Client.

View

The view is another JS class that is the actual view. So this the most senior class, that looks like it binds all the other classes together.

It is also what gets registered into the views registry, so ultimately I think this is the object that gets passed into the Window Action.

The Window Action will then pass in the xml template that the user defined, and the View passes that into the arch parser, then parses the result into the controller, attaching the model and renderer.

The controller then invokes the model to fetch the data, and passes it to the renderer.