Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):
- web._assets_utils: regroups the mixins and functions which *can*
(and so should) be available in every asset bundle
- web._assets_primary_variables: regroups the variables (or mixins
used as variables) which *can* (and so should) be available in
every asset bundle
- web._assets_secondary_variables: same as above but provides an
environnement where all the 'primary' ones are accessible. This is
for example useful to handle the community/enterprise split:
// Community primary variables
$o-pink-color: pink; // enterprise color
$o-brand-primary: blue;
// Enterprise primary variables
$o-brand-primary: $o-pink-color;
// Community secondary variables
$o-my-darker-primary: darken($o-brand-primary, 5%);
=> If there was only one variable template, enterprise edition would
have been able to define its primary color at the end but the
darker primary would not have been updated. Using the "!default"
system and putting enterprise definition above would not have
solved the problem as the $o-pink-color would not have been
accessible.
- web._assets_backend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the backend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
- web._assets_frontend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the frontend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:
- Find another way: your variable is probably useless, use bootstrap
variables directly or create a variable that will influence the
value of bootstrap variables. E.g. instead of declaring:
`$myvar: $bootstrapvar * 3`
and using $myvar alone, declare:
`$myvar: 3` and use `$myvar * $bootstrapvar` where needed.
- Declare a copy of the bootstrap variable and use that one. In that
case, you should also force-set the real bootstrap one to be sure
they match (this should be done in appropriate templates mentioned
above). E.g.
```
$o-boostrapvar: 5;
...
$boostrapvar: $o-bootstrapvar;
```
- Set your variable to null and set it to your bootstrap expression
in the file you will need it (where bootstrap variables are accessible)
without forgetting to add the !default flag to allow overriddes.
```
$myvar: null;
...
$myvar: $bootstrapvar * 5 !default;
```
This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).
Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).
This commit basically changes:
- Variables: @var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @mixin mixin-world {}
- Classes used as mixin: .my_class() -> @extend .my_class
- Here there were no other solution than to convert the use of
a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
- Still need to make sure last variable definition is at the
right place
The new views and widgets (at least some of them) first landed
in web_studio (v10), and they we moved later to web, so changes
in web_studio need to be applied in web.
We replace a bunch of formatting and parsing functions by an object
(parse or format) which can be used to dispatch on the correct type. It
allows us to remove the format_field and parse_field functions.
Also, we camelcase our new code and add some comments.
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
The JS widget is simplified, which a cleaner approach.
For the rendering part:
- the server reads the data
- the JS widget formats/organizes the data
- the template renders the data prepared by the widget
Quick summary of the modifications:
1. The associated field is a text field which contains JSON-encoded
data. The data are read server-side, and not client-side anymore.
2. The widget is an AbstractField, no need of ReinitializeWidgetMixin
anymore. No use of the FieldMonetary widget directly, but use a similar
format_value instead (inspired by ShowPaymentLineWidget).
3. Data formatting (call to format_value) is done in the widget, not in
the template anymore. This seems to be the standard way of doing, since
lunch was the only module where format_value was in the template and not
in the widget.
4. The addition of an order line is cleaner since all necessary data
are prepared server-side.
widget for displaying previous orders.
Detailed changes :
- previous order is not a computed field, with its own custom widget that has been designed
according the new spec for widgets;
- useless wizards have been removed, and replaced by some server actions that perform the
same action with less code and views;
- removed deprecated or incomplete reporting;
- some renaming to follow the new specifications of module coding
qsm-odoo