openerp-expert-framework team mailing list archive

[Xavier Morel <xmo@xxxxxxxxxxx>]

On 2012-12-10, at 13:20 , Valentin LAB wrote:
> BTW, it seems sequenceable list do not get a correct sequence at
> creation (they all stay at 0), which seems to be a design choice that I
> don't understand (this was already the case since... the beginning). I
> may have missed something, but moving a line around re-sequence
> correctly all lines... so I do not understand why this is not done also
> at creation.

Because it doesn't really make sense to do it by default? What should
the sequence number be for a creation "at top"? What if the object is
being created on the second page? Or even created from the first page
with a bunch of unseen record? Sequence numbers are not unique, and if
you need a default it's easy enough to define default values in term of
ir.sequence, postgres sequence or even just max() on the existing
records.

> Can you explain me the position of the cursor when using "arrow down",
> or when is the whole content of a cell selected by default ?

When done so automatically by your browser, which is why TAB does it
within a record, that's just the default browser behavior.

> When do we exit edition mode ? (down arrow and tab won't, left arrow at the end of the cell will).

[ESC], pressing the Discard link or Save button. In O2Ms, when moving
the focus out of the editable list as well.

> When is the content of the line saved ? (moving to another cell of the same line seems to do so, as enter key…)

Switching to a different row or pressing the [Save] button. In O2M, when
moving the focus out of the row (and editable list). The data-loss bug
when clicking on a different row was due to a synchronization error in
the form fields due to the way browsers sequence their DOM events.

(essentially form fields listen to the [change] DOM event to synchronize
the stored value and the UI value, but [change] only fires after [blur],
in many situations the editable listview programmatically triggers a
form save without any [blur] occurring and the form failed to correctly
synchronize the values to save)

> Why do the down arrow move to the end of the cell content at first
> press, then if at the end of the cell content it goes down ?

Moving to cell end on [down] is your browser's normal behavior, [up] and
[down] are only handled by the editable listview when the cursor is at
the end of the cell both to allow this behavior and (mostly) so that
textareas (multiline text fields) can be used at all.

> The new line created doesn't disappear when empty, and disappear in some cases (o2m widget, alt-tab out of browser) when filled !

o2ms attempt to save-on-blur (keeping 6.1 behavior), which might also be
the source for the alt-tab disappearance. It is possible that the
previous form bug made the listview believe no data had been entered in
the row, and thus discards the row on blur (rather than save it), in that
case it should now be fixed.