* Allow asserting state of record being edited (creating or modifying) through Editor#is_editing
* Improve setup_events to also dispatch keydown events
bzr revid: xmo@openerp.com-20120718124359-q0udajwbuhzpqjmi
extraction was broken: using _.bind/3 will partially apply the
function (first argument) on top of binding it to a context (second
argument), but the partial application will be from the *left* (which
is pretty much the only one making sense, short of kwargs).
handle_onwrite_record took its arguments the wrong way around: the
partially applied one was specified on the right and the "actually
applied" one was on the left, so it used the wrong argument and ended
up blowing up the rest of the code.
bzr revid: xmo@openerp.com-20120718101744-bbbshq60x2kqhob6
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