| Age | Commit message (Collapse) | Author |
|
*: mail, web_diagram
|
|
A record of the basic model may need to be displayed in different
views (e.g. a o2m record is displayed in the, e.g., Kanban view
inside the main form view, and if clicked, it is also displayed
in the form view opened in a dialog). However, the fields present
in those views may differ.
The previous implementation of fieldsInfo in the record didn't
handle that, as it was a dict whose keys were field names. With
this commit, the fieldsInfo is dict whose keys are view types, and
the values are dicts whose keys are field names (the fields of
the corresponding views, with they attrs in the view).
This allows to create multiple o2m records in a row in a form view.
|
|
* Data manager load_view returns a viewInfo object
* ViewInfo contains: the arch, fields and fieldsInfo objects, and some extra informations
* The fields come from the server and are frozen, without any view attributes (depend of the model).
* The fieldsInfo contains every view attributes and informations.
|
|
Before this commit, the AbstractField specialization to use to
instantiate a field was determined in the renderers. Now this is
regrouped in BasicView.
Note: renderers are still left free to not use the determined
Class (like Kanban and not editable List which instantiate widgets
only if the "widget" attribute is present).
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|