* DOM events sequence screwed up, requiring an explicit blur on the
current target to try and ensure the corresponding form widget would
register its own change event
* Requirement to stop the default behavior of keypress and keydown on
[Return] as they would somehow trigger the contextual menu of m2o
fields on the row, at the wrong place, when in a char field (I don't
even...)
* Delaying of the actual saving of the form (via `setTimeout`) to try
and ensure the blur/change event has had the time to propagate
correctly (and be handled) before we actually save
bzr revid: xmo@openerp.com-20120615055440-yn00uv4q8y29nboq
dataset.index was previously set to ``null`` in handler of [Create]
button (to fullfill contract with form view that dataset.index should
be ``null`` to indicate the creation of a new record with no id).
Issue: after setting the index to ``null``, the list view calls
``render_row_as_form`` which starts out trying to save a row being
edited (case: clicking of the [Create] button after having selected a
row for edition or after having written in a new record e.g. [Create]
-> type -> [Create] type -> ...). This tentative to save the existing
form would be performed in the context of a ``null`` dataset.index,
which the form view doesn't (and shouldn't, index should be that of
record *being edited*) expect.
-> first save in whatever dataset state is the current one, and *right
before* creating the new form (after having saved and/or discarded the
previous one) we have the id of the new record to edit (or ``null``),
find the index for *that* and set ``dataset.index`` to that (or
``null``) so the new form view can be created and opened in the right
context.
bzr revid: xmo@openerp.com-20120613153842-pd6xitjs8n003ogs
if the editable row's form isn't dirty, either nothing has been
entered in a new row or an existing row (being edited) has not been
altered, so can just discard the row (and reload it from cache if it's
an edition).
bzr revid: xmo@openerp.com-20120613153633-ms7i8t9lvdarxqi3
Change made registry inheritance "lazy", keeping a permanent relation
between child and parent and walking the tree to find matches.
But editable listviews relied on an implementation detail (that an
extension eagerly created keys in the children registry) and iterated
over the internal map of the child registry they'd just created to
replace the form keys with overridden versions of the form widgets.
Just iterate over form's registry, but really the editable list should
have its own Registry subclass doing that stuff more solidly.
bzr revid: xmo@openerp.com-20120209154844-zk2xuxdhhi57eqhp
* Deferred now provides creation flag and which record was edited on resolution
* Moved logic for editing next record (or creating a new one) to keyboard event handler
* Extracted keyboard even handler to prepare for new edition keys
bzr revid: xmo@openerp.com-20111208122946-221yve4amubqo1be
Form fields are extended/replaced in editable list view in order to
handle @invisible and @tree_invisible correctly in editable-list-form
context (base semantics of @invisible are different between listview
and formview, formview's @invisible is listview's @tree_invisible, and
instead of removing element from visible DOM listview's @invisible
only hides the element but it keeps the space it's taking).
As a result, listview editable needs to override Widget.update_dom for
pretty much all form widgets, in order to manage this difference in
behavior.
In case of @tree_invisible, it did so correctly setting and unsetting
its stuff and calling this.super() to execute the widget's actual
update_dom triggers **but it did not do so when the element was really
visible**.
As a result, in editable listview elements would never appear required
(blue background), invalid (red background) or disabled (gray),
although they were correctly set up, because the display layer was
never updated.
bzr revid: xmo@openerp.com-20111004151031-65o0q8e86op7kdks
Xavier Morel
niv-openerp
Hiral Patel (OpenERP)
Fabien Meghazi
Antony Lesuisse
Jacques-Etienne Baudoux