also fix various bits of code looking for an absence of @data-id, so that they look for a false @data-id to match the row of the new record instead
bzr revid: xmo@openerp.com-20120709084652-rt1ffu2ea20scw53
Instead, create a new one at each on_loaded.
Editor is not restartable because the formview wedges itself if its on_loaded is called more than once
bzr revid: xmo@openerp.com-20120709080604-er1l6bn5eespue59
namely, if the list view fields have e.g. attributes associated, the
computation of the domains blow up
also, always create an editor in the listview (if the editable
listview module has been installed), avoids blowing up 'safety' calls
to #ensureSaved. An alternative would be to fix #ensureSaved not to
blow up if there's no editor, but that means third parties which
*know* there may be an editor in the list view can't easily hook up to
it.
Things will have to change anyway as currently toggling a list view
from not-editable to editable after on_loaded has been called will not
work correctly (it won't start the editor), which is shitty.
bzr revid: xmo@openerp.com-20120705143721-4fiz64k7fka4052k
* Move prev/next behavior after save to ListView
* Have fetching of row for a record be a method chain on Group/List
* Have edition behavior be fully specified in ListView
bzr revid: xmo@openerp.com-20120702132217-ni1byjkf7t6tr5a4
* 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
Xavier Morel
niv-openerp
Hiral Patel (OpenERP)
Fabien Meghazi