Description

Requirements

Iteration 1

• (R1) For LiveTable source, adding an entry creates a new page
• (R2) Entries can be added quickly, and only the keyboard is needed for that

Iteration 2

• (R3) Immediate and seemless transition between editable cells
• (R4) Two axes navigation with arrow keys
• (R5) While edition process is active, cells are fixed and do not distract the user by moving around
• (R6) No visible difference between a new row and an existing row, both use the same displayers
• (R7) Same save process when editing a row or creating one, either transactional or automatic
• (R8) Support for a maximized view, giving more space to the livedata when editing
• (R9) Template support for default values
• (R10) Naming strategy using user input as page title

Current State

Existing "Add entry" button

The current Live Data implementation already includes a "Add entry" button for the Table and Card layout. It is only displayed if the current source declares a "addEntry" action:

Iteration 1

Alternatives

Page Creation

On clicking "Add entry":

1. Ask for full page location
2. Ask for page name and use configured space
3. Ask for page name and assume current space
4. Don't ask for anything, display (empty) page location in a required editable column (or option 1 if the LiveData does not have the doc.location column)
5. Don't ask for anything, display (empty) page name in a required editable column and assume current space (or option 2 if the LiveData does not have the doc.title column)
6. Don't ask for anything, assume current space and auto-generate page name

Display Update

For pagination, once a new entry has been added:

1. Automatically move to the page that contains the new entry
2. Display the new row in the current page
   1. Replace the previous last row
   2. Ignore page limits until refresh
3. Do nothing, the new entry will only be displayed if the user is on the page that should display it

For filters, once a new entry has been added:

1. Keep enforcing filters, consider the user knows what they are doing
2. Display the new row even if it should be filtered out

Proposal

Sequence to quickly create rows:

1. If the user has the necessary edit rights, the live data displays an "edit mode" checkbox. Once checked, the livedata is in edit mode and displays all available columns.
2. The user clicks the "Add entry" button.
3. If the Live Data displays the doc.title column, go to step 3 and make it editable. Otherwise, a popup opens, similar to AWM creation process, to input a page name. The input box is autofocused and can be validated with the return key.
   
4. Here, the new row appears and the first editable column is opened in edit mode and focused.
   
5. Hitting Tab should go to the next editable column, Shift+Tab to the previous one (if available) (or cycle through a list if the editor is a list, and switch columns on first and last element only)
   
6. Once done with the current line, multiple choices are available:
   • Hitting Tab would eventually cycle back to the Add Entry button, validating the row.
   • Pressing Return closes all opened editable fields, validating the row.
   • Pressing the validation button closes all opened editable fields, validating the row.
   • Pressing Ctrl+Return closes all opened editable fields, validating the row, and also creates a new row (go back to step 1).

LD parameter change:

• Add a new sourceParameter newRowNamingStrategy, only support the value template so far.
• Add a new sourceParameter newRowNamingTemplate, used to automatically name the pages corresponding to new rows.

This iteration was accepted in the forum and implemented.

Iteration 2

After some light use, limitations were raised and became R3 to R10.

Cell edition (R3, R4)

Still in discussion

When editing a cell (in edit mode), there are a few ways to improve smoothness:

1. Open all the cells of the focused row in edition at the same time. Fixes layout when switching cells horizontally (R3), and makes displaying a draft row in view mode impossible (R6)
2. Open all the cells of the whole livedata in edition at the same time. Fixes layout when switching cells (R3), makes displaying a draft row in view mode impossible (R6), but is heavy
3. Open editor for the selected cell in a popover. Smooth, does not require recomputing layouts (R3)

Entry creation and save process (R6, R7)

Right now, cells for existing rows are saved automatically on switch, and new rows require a manual save. Options are to:

1. Keep saving each cell on switch, and do it also for draft rows. Automatic save always (R7), requires creating new page and XObject before there is anything to display in view mode (R6)
2. Automatic save on row switch. Automatic save always (R7), only make sense if we consider a row-based edit mode
3. Manual save for row. Transactional save always (R7), only make sense if we consider a row-based edit mode

XObjects are currently created when the user manually clicks the save action. Options are to:

1. Keep creating XObjects only when there is a manual save
2. Always create a new XObject when a user clicks "Add entry", before any input, and remove it if the user then leaves it empty (R6, R7)
3. Always create a new XObject when a user clicks "Add entry", before any input, and keep it even if the user then leaves it empty (R6, R7). Note that a user missing DELETE rights could no longer clean out an empty page created by mistake.

Decision: the save process should be automatic in both cases (R7).

This leaves the question of when should the page and object be created, here are the options:

1. Create as soon as possible. The page and its XObject are created when clicking "Add entry". The simplest option, and the only one where there is no concept of draft. When a naming strategy requiring user input is implemented (R10), it will likely need a popup to get it.
2. Create on the first edited value. The row appears empty and the page is created when the user edits the first cell.
   1. For naming strategies that require user input, creation is delayed until the mandatory fields are actually filled, which requires support for mandatory properties and a clear indication that the row is still a draft until they are set. Displayers stay broken until the first save, which might be acceptable as long as the row is marked as a draft.
   2. Aways create the page, even without the required user input, under a temporary unique name, then move it afterwards on a best-effort basis to follow the naming strategy (e.g., if Foo already exists, the page would be moved to Foo~1). This solves the displayer problem, at the cost of some pages temporarily not following the naming strategy.
3. Server-side draft. Instead of the single save endpoint we have now, use a proper server-side createDraft/commitDraft strategy, with the draft held server-side as an unsaved document living in the user session. Discarding a draft would not require DELETE rights, and there is no client-side draft to maintain since the server is the only source of truth. Cell saves appear automatic and displayers work. In exchange, the UI has to distinguish drafts from committed entries, and this is the alternative requiring the most changes to Live Data's current API.
   1. All the entries in the same table, with an indication on drafts and a "commit"/"discard" button.
   2. Two separate tables, with a "Save all drafts" button and a per-row "discard" button.

Data refresh handling (R5)

Whenever a cell is saved, if the livedata has rules for pagination and/or filters/orders, whole rows could move around or even disappear while the user is actively trying to edit them. To freeze the order when in edit mode:

1. On save, ignore existing filters and pagination rules that could reorder or mask the data (R5). The user can still apply filters manually that force a refresh
2. On save, ignore existing filters and pagination rules that could reorder or mask the data (R5). There is no way to unfreeze the layout without first exiting edit mode

Decision: Option 1.

Proposal

The alternatives are currently being discussed in the forum.