<feed xmlns='http://www.w3.org/2005/Atom'>
<title>Odoo/addons/web/static/src/js/compatibility.js, branch 14.0</title>
<subtitle>The current checkout of upstream Odoo</subtitle>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/'/>
<entry>
<title>[REF] web, *: redesign all JS views</title>
<updated>2017-04-11T17:44:38+00:00</updated>
<author>
<name>Géry Debongnie</name>
<email>ged@odoo.com</email>
</author>
<published>2017-03-05T09:05:56+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=905e01921f3c3ef43ace6fc537d1d8c0d280002c'/>
<id>905e01921f3c3ef43ace6fc537d1d8c0d280002c</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] web: refactor and simplify web.core</title>
<updated>2016-06-17T11:32:37+00:00</updated>
<author>
<name>Géry Debongnie</name>
<email>ged@odoo.com</email>
</author>
<published>2016-06-16T11:44:21+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=00120a9271b8c52c1ed3a392e0e66f3e8c9a6893'/>
<id>00120a9271b8c52c1ed3a392e0e66f3e8c9a6893</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[MERGE] forward port of branch saas-10 up to b26fd22</title>
<updated>2016-05-17T12:39:05+00:00</updated>
<author>
<name>Christophe Simonis</name>
<email>chs@odoo.com</email>
</author>
<published>2016-05-17T12:39:05+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=e38ddcfeae647da3da19fee0491606bc70df0dd3'/>
<id>e38ddcfeae647da3da19fee0491606bc70df0dd3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[FIX] web: update compatibility layer</title>
<updated>2016-05-17T08:47:26+00:00</updated>
<author>
<name>Stanislav Sokolko</name>
<email>s.sokolko@gmail.com</email>
</author>
<published>2016-04-25T15:18:15+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=0632a40b80474940004380e14e4754446a4332e9'/>
<id>0632a40b80474940004380e14e4754446a4332e9</id>
<content type='text'>
this commit adds better support in the compatibility layer of the
js framework.  This is necessary if one wants to follow the
official tutorial.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
this commit adds better support in the compatibility layer of the
js framework.  This is necessary if one wants to follow the
official tutorial.
</pre>
</div>
</content>
</entry>
<entry>
<title>[REF] web: stop duplicating web</title>
<updated>2016-04-21T13:21:39+00:00</updated>
<author>
<name>Aaron Bohy</name>
<email>aab@odoo.com</email>
</author>
<published>2016-04-08T12:53:34+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=977db823c7c84e9edc7c8cf8384eb9cf47275b3a'/>
<id>977db823c7c84e9edc7c8cf8384eb9cf47275b3a</id>
<content type='text'>
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.

Mainly:
 - JS refactoring and linting
 - Conversion of .sass into .less split into multiple files
 - Templates cleaning and DOM simplification
 - Re-generation of web.pot, and update of .po files
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.

Mainly:
 - JS refactoring and linting
 - Conversion of .sass into .less split into multiple files
 - Templates cleaning and DOM simplification
 - Re-generation of web.pot, and update of .po files
</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] openerp, web(_*): batch views RPCs</title>
<updated>2016-03-18T09:44:52+00:00</updated>
<author>
<name>Aaron Bohy</name>
<email>aab@odoo.com</email>
</author>
<published>2016-03-16T08:53:23+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=002660a9b05cf8620e1c5287a8538ac5e806d59e'/>
<id>002660a9b05cf8620e1c5287a8538ac5e806d59e</id>
<content type='text'>
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.

Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.

The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.

Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
  heavy processing.
- Remove view_type attribute from views as it was used to call
  fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
  lifecycle of widgets (init -&gt; willStart -&gt; start -&gt; destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
  action buttons to wrap handlers to ensure that they are executed only if
  the form_view is the current active view. This is not useful anymore as
  from v9, views and their control panel are appended in the DOM
  simultaneously, so one can't click on a button of a view which is not the
  current active view.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Load the fields_view of all views of the action together. If a searchview is
required, also load its fields_view and its filters.

Use lazy-loading for fields as they are required for the Pivot and Graph
views only, and may be used by Filters and GroupBy menus of the Search view
if the users clicks on 'Add a custom Filter/Group'.

The fields are thus also loaded directly if the first view of the action is
Pivot or Graph, and otherwise, they are lazy-loaded when/if the user opens
a Pivot or Graph view, or if he wants to add a custom Filter/Group.

Some refactoring of views API as well:
- Views must now be instantiated with their fields_view
- Move code requiring fields_view from start() to init(), or willStart() for
  heavy processing.
- Remove view_type attribute from views as it was used to call
  fields_view_get.
- Remove view_id parameter to views' init as it is no longer used.
- Move duplicate code from various views' init to the View widget.
- Remove view_loading() function from views as they now follow the classical
  lifecycle of widgets (init -&gt; willStart -&gt; start -&gt; destroy).
- Searchview now extends View like all other views.
- Remove useless function guard_active() as it was used for the form_view's
  action buttons to wrap handlers to ensure that they are executed only if
  the form_view is the current active view. This is not useful anymore as
  from v9, views and their control panel are appended in the DOM
  simultaneously, so one can't click on a button of a view which is not the
  current active view.
</pre>
</div>
</content>
</entry>
<entry>
<title>[FIX] web, mail: move 'mail.compatibility' in mail</title>
<updated>2015-07-22T10:15:25+00:00</updated>
<author>
<name>Christophe Matthieu</name>
<email>chm@odoo.com</email>
</author>
<published>2015-07-17T10:47:38+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=242e5231f02f1016af20369ceb2c38d825287f24'/>
<id>242e5231f02f1016af20369ceb2c38d825287f24</id>
<content type='text'>
'mail.compatibility' javascript module require 'mail.mail'
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'mail.compatibility' javascript module require 'mail.mail'
</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] web: split model.js into model.js and data_model.js. Web js modules must call web.DataModel.</title>
<updated>2015-07-10T14:32:35+00:00</updated>
<author>
<name>Christophe Matthieu</name>
<email>chm@odoo.com</email>
</author>
<published>2015-07-08T08:29:42+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=500c33b18406c2663366ce6eefc5d8e258d6f681'/>
<id>500c33b18406c2663366ce6eefc5d8e258d6f681</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] Web: ListView: semantics classes for row decoration</title>
<updated>2015-05-15T07:17:18+00:00</updated>
<author>
<name>Aaron Bohy</name>
<email>aab@odoo.com</email>
</author>
<published>2015-05-13T12:20:18+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=e7ff2d2c6a564823dd05e2d53cb32c47b826caed'/>
<id>e7ff2d2c6a564823dd05e2d53cb32c47b826caed</id>
<content type='text'>
based on bootstrap contextual colors, and bold/italic fonts.

Backward compatibility is ensured as the ListView is monkey-patched
to keep interpreting colors and fonts attributes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
based on bootstrap contextual colors, and bold/italic fonts.

Backward compatibility is ensured as the ListView is monkey-patched
to keep interpreting colors and fonts attributes.
</pre>
</div>
</content>
</entry>
<entry>
<title>[IMP] web+addons: improvement to module system</title>
<updated>2015-03-18T08:23:37+00:00</updated>
<author>
<name>Géry Debongnie</name>
<email>ged@odoo.com</email>
</author>
<published>2015-03-13T13:02:50+00:00</published>
<link rel='alternate' type='text/html' href='http://erp.ceuconsult.com:9000/Odoo/commit/?id=4fdf74fe21b9fb99ed9cdcb1a0ef2e21d34dafed'/>
<id>4fdf74fe21b9fb99ed9cdcb1a0ef2e21d34dafed</id>
<content type='text'>
The module system needs to know the dependencies of a given module
before executing the function.  This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.

But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The module system needs to know the dependencies of a given module
before executing the function.  This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.

But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
</pre>
</div>
</content>
</entry>
</feed>
