Odoo Architecture - vec-ltd/odoo-docs GitHub Wiki

The main thing to understand about Odoo, is this; at its core, it is basically a web framework. The backend is written in Python and uses Postgresql, and the frontend is an SPA written in their own JS framework called Owl.

So when you open up Odoo, the backend is serving up an Owl SPA, which then interacts with the Python backend to perform operations, read data etc.

Almost everything is configured using XML, from the backend configuration, to the frontend templates. Whereas in ReactJS you might use JSX templates to define a frontend component, in Odoo OWL uses XML templates to define the layout of a frontend component.

The reason for this, is XML is highly extensible. You can define an XML object in multiple places and as long as it matches on the ID, you can essentially 'patch' the same object later on. This is a crucial aspect of how development in Odoo works.

As an example, let's suppose we define an instance of MyObject with id 123:

<MyObject id="123">
  <field name="comment" />
</MyObject>

Later on, in a completely different part of the project, we could define something like this:

<MyObject id="123">
  <field name="image" />
</MyObject>

And Xml has the capability to then merge these two documents, so in effect, MyObject with id 123 will actually have 2 fields.

Ok so why does this matter?

Beyond the core functionality, every other feature in Odoo is implemented by a Module.

A Module will define things like:

• Database entities
• Frontend components
• XML layout templates
• Access rules

Odoo ships a lot of free modules that covers much basic functionality. For example, accounting, project management, inventory etc. If you want to extend any of these modules, add to it or even alter its functionality, the way you do it is to create a NEW module, and then hook into the existing objects from the other module. By matching on things like the XML ID, you can add, remove or update existing configuration or functionality from other Odoo modules.

You can also build entirely new standalone modules as well, and install those. These can be totally isolated from the rest of the system, but simply leveraging the capabilities of the Odoo framework.

So the benefit of using Odoo is you get a lot of functionality out of the box, which you can also customise to your own needs.

Another benefit of Odoo, is that there are pre-defined, standard ways of solving common problems. Like most web frameworks, they try to provide solutions to common problems so you don't have to reinvent the wheel.

Odoo takes this a step further, for example handling database migrations for you, automatically exposing a REST API, and making scaffolding CRUD forms using very little code.

A traditional web framework, like Vue + Laravel, you have all the tools there, but you still basically have to build all the forms, build endpoints to handle the requests, build authentication and validation etc.

Odoo handles all that for you, as long as you don't stray too far from the "Odoo way" of doing things.

Basically if you have Business Objects / Entities, with fields and relations, and you want simple CRUD forms for entering and viewing these entities, you can scaffold those things up extremely quickly in comparison to other Web Frameworks.

By simply defining a few fields in the Odoo ORM, and a couple of templates to describe the layout, you can have all this done in a very short space of time.

Of course the drawback of this, is if you want to do anything else, you have to do a lot more work yourself, and you need a good understanding of the different Odoo APIs and how they actually work under the hood.

You will find documentation on these things to be lacking in most cases, hence why this project exists in the first place.

One of the features of the Odoo system, is that it basically eats its own dog food at every opportunity.

The core implementation is quite minimal, it just provides only enough features to bootstrap the application and allow everything else to run. So a lot of Odoo functionality is actually present in the default modules they provide.

Another relevant point is that almost everything is data driven, primarily through XML templates. So Odoo core provides the basic primitives, and from that the entire framework is built.

So almost everything you'd want to do (except heavy customisation), is done through passing XML documents into the Odoo core, instead of writing tons of code.

Want to create a form? Just create an XML document to describe it. Want the user to be able to perform an action? Write an XML document describing the action they can take and how they take it. etc.

These XML documents get loaded into the database, but you can also edit them on the fly which has the effect of then altering the entire behaviour of the system or parts of the system.

So it's a bit like meta-programming. Odoo have almost built an XML DSL for the web framework, so you can just keep adding or editing the XML documents to achieve what you want to achieve.

Another consequence of this, is you can essentially add to the Odoo core functionality (as long as you respect the internal APIs), and write JS code that hooks seamlessly into Odoo and will accept these XML documents and know what to do with them as well.

The Web Client is an SPA that is based on the Owl framework. Owl is only responsible however for providing the primitives of Component rendering, reactivity etc.

You could build any front end application in Owl if you wanted to. So the Odoo Web Client builds on top of Owl a certain structure, and we must understand that structure in order to successfully customise Odoo.

The Web Client provides a lot of additional things, like for example an ORM service that we can use to perform database operations. It has a set layout, with menus, and the main Window Action from which you are viewing your current model (and the type of view).

You can replace this Window Action with your own Client Action (the terms are a bit confusing I know), so that you can construct your own custom view.

But really think of the Web Client like this: it has all the menus and existing infrastructure there, and you get to choose what 'Action' is on display at any time.

So you can use all the default Action Views there are (like tree, form, kanban etc.), or you can define your own Action View (which can then be fed arbitrary model data), or you can replace the main Action View with a Client Action (i.e. a completely custom component that could be pulling in multiple records, or displaying charts, whatever you can think of).