Chapter 1: Architecture Overview¶
Multitier application¶
Flectra follows a multitier architecture, meaning that the presentation, the business logic and the data storage are separated. More specifically, it uses a three-tier architecture (image from Wikipedia):
The presentation tier is a combination of HTML5, JavaScript and CSS. The logic tier is exclusively written in Python, while the data tier only supports PostgreSQL as an RDBMS.
Depending on the scope of your module, Flectra development can be done in any of these tiers. Therefore, before going any further, it may be a good idea to refresh your memory if you don’t have an intermediate level in these topics.
In order to go through this tutorial, you will need a very basic knowledge of HTML and an intermediate level of Python. Advanced topics will require more knowledge in the other subjects. There are plenty of tutorials freely accessible, so we cannot recommend one over another since it depends on your background.
For reference this is the official Python tutorial.
Flectra modules¶
Both server and client extensions are packaged as modules which are optionally loaded in a database. A module is a collection of functions and data that target a single purpose.
Flectra modules can either add brand new business logic to an Flectra system or alter and extend existing business logic. One module can be created to add your country’s accounting rules to Flectra’s generic accounting support, while a different module can add support for real-time visualisation of a bus fleet.
Everything in Flectra starts and ends with modules.
Terminology: developers group their business features in Flectra modules. The main user-facing
modules are flagged and exposed as Apps, but a majority of the modules aren’t Apps. Modules
may also be referred to as addons and the directories where the Flectra server finds them
form the addons_path
.
Composition of a module¶
An Flectra module can contain a number of elements:
- Business objects
A business object (e.g. an invoice) is declared as a Python class. The fields defined in these classes are automatically mapped to database columns thanks to the ORM layer.
- Object views
Define UI display
- Data files
XML or CSV files declaring the model data:
configuration data (modules parametrization, security rules),
demonstration data
and more
- Web controllers
Handle requests from web browsers
- Static web data
Images, CSS or JavaScript files used by the web interface or website
None of these elements are mandatory. Some modules may only add data files (e.g. country-specific accounting configuration), while others may only add business objects. During this training, we will create business objects, object views and data files. Web controllers and static web data are advanced topics.
Module structure¶
Each module is a directory within a module directory. Module directories
are specified by using the --addons-path
option.
An Flectra module is declared by its manifest.
When an Flectra module includes business objects (i.e. Python files), they are organized as a
Python package
with a __init__.py
file. This file contains import instructions for various Python
files in the module.
Here is a simplified module directory:
module
├── models
│ ├── *.py
│ └── __init__.py
├── data
│ └── *.xml
├── __init__.py
└── __manifest__.py
Flectra Editions¶
Flectra is available in two versions: Flectra Professional (licensed & shared sources) and Flectra Community (open-source). In addition to services such as support or upgrades, the Professional version provides extra functionalities to Flectra. From a technical point-of-view, these functionalities are simply new modules installed on top of the modules provided by the Community version.
Ready to start? Before writing actual code, let’s go to the next chapter to review the Flectra installation process. Even if Flectra is already running on your system, we strongly suggest you go through this chapter to make sure we start on the same page during the development of our new application.