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).
Summernote is using LESS and no SCSS version exists (at least
officially). As summernote is meant to be replaced in the future and
that the LESS file was already overridden directly by Odoo, this
commit converts the LESS file to CSS once and for all.
This rev. introduces a new test suite meant to test the webclient
components on mobile devices. The key 'config.device.isMobile' is
forced to true in this test suite, so that mobile specific JS files
are properly executed, which isn't the case in the classic JS test
suite (setting isMobile to true in the test definition is too late,
as the JS files are already processed).
For now, this new test suite contains a single test, which was
skipped until this rev. as it couldn't be executed in the classical
JS test suite.
Both suites are executed at each build of the runbot, and they
can be manually executed from the webclient as well (via the debug
manager).
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
Before this commit, the session object was responsible for loading the
translations in the backend only. There was then ugly code in web_editor
(which is also loaded in backend...) which was doing "if frontend then
load translations by myself". This code was also translating templates
while this is the qweb object's job. Now session is always responsible
for loading translation.
Note: the session object should be refactored/split.
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
Commit 933949085d added the odoo variable
definition in the iframe template so the condition which checked if
odoo.define is available had to be adapted.
These colors were usually hardcoded in some snippets (.s_banner for
example) to increase text legibility over background images.
This commit will let the user personalize them.
Previous implementation allowed to run tour as a non-superuser but
this was only working in the backend where the static file tip.xml
is always loaded. In the frontend or in other non-backend context,
this file has to be loaded just before trying to launch the tour as
a non superuser (indeed, previous implementation loaded the file in
the frontend only if the user is a superuser).
* web_editor, website, mass_mailing
This menu allowed to scroll to the snippets sections by clicking on
their corresponding icons. It was useless as the sections are not
taking a lot of height. This also appeared buggy as clicking on the
last icon highlighted only the second one as this second one was still
the first section visible on the screen when the last section was
fully visible.
This also added fours buttons to the interface which contains already a
lot of them. Now this is replaced by a title "Add blocks" which makes
the editor cleaner and also improved the performance to enter the edit
mode.
session_instance.js moved from framework/ to services/ and renamed into
session.js, which required to change the bundles in report and web_editor
addons.
The assets_frontend inheritance made by the web_editor module should be
the first to be done as the website.assets_frontend rules have to come
after (LESS variables overridden).
Since the website/web_editor split, the mt/mb definitions were not
included in reports anymore. Those were not the only rules that
were forgotten. In 9.0, as a fix, those rules were added back in the
report.css file.
As the assets have been refactored in saas-10, the fix here is to
link the missing file (unique in saas-10) in the report assets.
* Remove recursive assets inclusions (i.e. assets_editor was including
assets_common, summernote, ...)
* Better construct the assets (link, then script + type attribute)
* Better include the assets (split js / css, always use t-call-assets)
* Simplifies the number of assets
* Move bootstrap js to assets common
* assets_frontend is now created by web module to allow using it on the
connexion page but also in the web_editor, where colors have to be
bootstrap/theme ones. Note: if a module depends on website, then keep
using the inherit_id="WEBSITE.assets_frontend"
Before, the whole editor UI was redefined for web_editor, each
mass_mailing template, website builder, ... Now they all inherit
from the web_editor one.
Some feature of the iframe embedded editor may require csrf token
present, thus it has been added in the same way that cea29e0c0 did.
The web editor iframe template is also used to display the value without
editing it and in this instance having the csrf has no meaning.
opw-656685
Difficulty for the user to understand how to change the images.
Some options summernote being in the bar and the other in the snippets editor.
Need to merge this options.
Add "web_editor_inside_iframe" id in web_editor iframe template to apply css style only when the field is in html field.
Remove "content" css media query in iframe editor to remove scrollbar.
The original commit by fka used to define less variables like this:
@px-4: 4px
@px-8: 8px
The goal was to be able to change the margin values in
media queries for smaller screens.
However, as the less is only compiled once in css, those
variables didn't really help as you couldn't redefine them
from inside a media query and have the less magically
reassign the margins on the fly.
I created less helper functions to be able to easily redefine
the margins for smaller screens from inside media queries.
The task also required to replace the nbsp in the html by the
newly created mr and ml classes.
This is also the first phase of the sass -> less transition.
qsm-odoo