openerp-expert-framework team mailing list archive

[Valentin LAB <valentin.lab@xxxxxxxxxxx>]

On 11/12/12 16:27, Xavier Morel wrote:
> 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?

I am afraid that this is not a question even if there's a question mark 
at the end. And besides, it's not so argumented.

I'm concerned by these issues:
- new created elements that appear at creation at the bottom of the 
list, are randomly positionned after quitting the view then reloading it.
- most of the sequenceable list I can think about are sequenceable to 
get a fixed order that should be relied upon. Invoice lines, sale order 
lines, order should remain stable upon reload.

I just don't understand why it's not enforced at creation time while it 
is enforced on all element at drag-and-drop time.

I'll try to be clear what I do not understand in the following answers 
to your question.

> What should the sequence number be for a creation "at top"?

Well, "0", and the next element would be "1", "2" ... this is exactly 
what is done when you move a line around (with drag-and-drop) in the 
editable tree view widget. Why should this be an issue at creation time 
and not at drag-and-drop time ?

My idea of this is that "sequence" attribute is only a hidden param that 
help openerp to store the actual order in an ordered list of elements. 
This should not be considered the same as the "sequence" used for views 
for example, which are more "priority" than sequences. (And AFAIK, there 
are no editable widget to change sequence with a drag-and-drop in 
OpenERP for views).

The fact that the editable widget overwrite all sequence number to be 
unique and sequential upon drag-and-drop is central to my argumentation. 
If this is the case, this widget should also arrange sequences correctly 
to keep these property true at creation time (uniqueness and sequentiality).

I probably didn't catch all the subtlety of your questions.

> What if the object is being created on the second page?

I don't see what issues this brings... Do you want to move an element 
from the second page to the first ? well this is not a creation issue, 
and this is an issue anyway with the current widget.

> Or even created from the first page with a bunch of unseen record?

Again, I can't see the issue. You are doing it on drag and drop. There 
must be something I didn't catch and I would be happy to learn what.

> 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.

I can't see a case where having a sequenceable list being not sequenced 
useful, but if I accept your point of view, why the hell the widget will 
rewrite all the sequences of each elements of the list with values "0", 
"1", "2" ...?

Why do you want to make that default value creation a special case that 
should be configured carefully at creation time by the developper, and 
just remove all these values upon drag-and-drop of a random element in 
the list ?

> > 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.

The cursor position is still difficult to understand while using ENTER 
key on runbot.

And TAB wouldn't select first cell content by default (ie: when hitting 
tab on the last cell of the row, it goes to the first cell of the next 
row without selecting it's content), but would select content of any 
following cell on the same line.

> > 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.

If you hit [ESC], this will discard your content without warning... but 
if you click back on the cell, your "discarded" content will pop back 
up... This is another bug BTW. Tested on current runbot.

Shift-TAB doesn't go up one line when on first cell of line, but TAB 
does go down while on last cell. Is this intentional also ?

> > 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.

Okay, arrow movement seems consistent, I was mislead because tried to 
find a coherence with the position of the cursor in the cell after 
hitting the ENTER key (try at the end, beginning, in the cell, and after 
deleting char, or a small selection in the current cell).

And BTW, isn't it possible to move up only if the cursor is on line 0 of 
its content ? (And down only if cusor is on last line of its content ?). 
The current runbot behavior in good enough for me anyway.

I'll put all the following review report on the bug request. Thanks for 
the good work... there's more bug to tackle, but this is going well as 
really annoying bugs are corrected.

Don't get me wrong: this code needs more love.

I found my bug report with "Fix released" tag applied... But I feel it 
doesn't deserve it yet.

I asked for a complete review of the widget here and in the bug report, 
not just random bug fixes.

--
Valentin LAB
Ingénieur Développement

tel:  +33 6 71 39 62 13
mail: valentin.lab@xxxxxxxxxxx