Forms in listview

Rational

Quite often people would like to have more control over the layout and the information display in ListViews then the current pure table layout.

This includes being able to display some M2M or O2M fields.

This kind of view could be used for the addresses in the party view for example.

Proposal

Thanks to the swtich to GTK-3, we now have the opportunity to use GtkListBoxes.

Which allows to have any kind of widget used in the rows displayed.

For sao, given the “flexibility” of the HTML it shouldn’t be a problem to have the same kind of behaviour.

Implementation

In order to reuse a maximum of code from the form views some preliminary work must be done to have generci parsing of the XML and removing the use of record in the widget’s method calls (by using the record from the view).

Afterwards we will add a new type of view (list-form or something like that) that will be specified using the form syntax.

1 Like

The save button should save all the records (like the list does).
But I think we should define what happens if user made some change in record A and then set the focus on record B. Are we going to save record A? If not, the client should check all the records before allowing the close the tab.
Will there be a search bar? I think it is possible but will we use all the fields of the view?

Shouldn’t it work like the editabletree: save the record and prevent moving if the record failed the validation ?

I do not think so. List has this behavior because it can be very large and so we should not test all the records for performance reason. But here we are with small list, so I think we could just save at the end and test all records.
Also the behavior of the list against invalid record is not very user friendly, I think it will be better if we could avoid it on this new view.

I don’t understand the aim of the change. What would it change in the addresses view of the party?

Yes, we have often feedback that users do not understand well the form in the One2Many. As a party will have few addresses, we think that the general form will be better understood by using such list-form view.

I am a bit late to the party but if you need some visual clue about what it will look like here’s a tweet I made with a screenshot of the implementation in tryton:

Thank you for the picture, So finally we have a kind of Kanban view in Tryton, cool.

My understanding of Kanban is more something that you can drag and drop from column to column like:

Here it’s more like a short list of forms (that should be short too).

BTW here’s the bug and its review: Add new view type: listform (#8185) · Issues · Tryton / Tryton · GitLab

This is just the formalism. Kanban is a way to do lean management. Tryton has already the required tools for lean management.
Another common mistake is to name “kanban” the agile board. Again it is just a visual presentation that could be replaced by buttons and tabs.

Now back to the list-form. For me, it will be more often used as a One2Many with a small form inside (1-3 fields). Or as an second alternative view of a One2Many instead of the form/popup.

I agree.

However, it might be a good idea to allow the formlist to have a “direction” which could be “vertical” (default) or “horizontal”. Would that be possible? Maybe in some cases it could be a good idea to allow adding records on the left instead of the bottom.

I agree it is just a visual presentation of data, but I don’t think it can usually be replaced by buttons and tabs.
The key feature of such a board is that you see all the items in different states at the same time (and it can clearly identified in which ones are in each state), and there’s no way of doing that in Tryton right now so clearly.

But that’s probably for another thread…

1 Like

This topic was automatically closed after 14 days. New replies are no longer allowed.