Live Data's entry creation save behavior

Development
1

Hi everyone,

This proposal is a follow-up to UI improvements for Live Data's edit mode, focusing on the save behavior for new entries.
As a reminder, an issue with the current implementation of entry creation is that it’s inconsistent with the edition of existing entries while in edit mode: editing an existing entry supports automatic save for each cell, while new entries stay as drafts until they are manually committed by the user. Draft entries also do not support XObject displayers for data inputted but not committed yet.

In the previous discussion, it was decided that the best course of action going forward would be to support automatic save for both situations. This leads to a few alternatives on how to implement this:

1. Create as soon as possible

The page and its XObject are created on “Add entry”, before any cell input. A consequence for this is that, when we later implement a naming strategy requiring user input (e.g., we ask the user to enter the page title), we will likely need to use a popup.

This is the simplest option. A limitation is that, if a user is missing DELETE rights, they may not be able to undo accidentally creating a new page by deleting it.

2. Create on the first edited value

The row appears empty, and the page is created when the user edits the first cell. In the case of naming strategies that require user inputs, we could delay the creation until these fields are actually input (this would require support for mandatory properties, and a clear indication to the user that the row is still a draft until they are set).

In the case of mandatory inputs, the displayers would still appear broken until the first save (but it shouldn’t be a huge problem if the row is properly marked as a draft).

There is a 2.b alternative: we could always create the page even if we don’t have the required user-input, using a temporary unique name, and then move it afterwards (as best-effort to follow the naming strategy, e.g., if Foo already exists somehow the page could be moved to Foo~1). This solves the displayers issue but may add a small complexity for the users (with some pages temporarily not following the naming strategy at all).

3. Server-side draft

Instead of a single save endpoint like we have now, we could consider a proper server-side createDraft / commitDraft strategy, with the draft held server-side as an unsaved document (living in the user session, like what TemporaryAttachmentSessionsManager does).

Discarding a draft would not require delete rights, and we don’t need to maintain client-side drafts since the server is the only source of truth. Saving of cells appear automatic and displayers should work. But the UI will need to make a clear distinction between drafts and non-drafts:

  • a. All the entries in the same table with indications for drafts and a “commit”/“discard” button
  • b. Two different tables, with a “Save all drafts” button and a per-row “discard” button

This alternative might require the most changes to LiveData’s current API.

Personally, after considering all these, I think option 2.b would be the best trade-off here. A click on “add entry” does not have any side-effect until the user actually writes something, and the fact some pages might have different naming conventions should be quite clear by simply looking at the state of the Live Data (i.e., it would still match the displayed values).

Thanks.

2

I don’t think one case miss the DELETE right on a document they created.

I said -1 without giving arguments in the previous discussion.
I’d like to move to -0 mainly because:

  • It does not make much sense to save something empty
  • When a naming strategy requiring a user input is active, it might be annoying to get asked for the value whenever a new row is added (though that’s exactly what happens with AWM when adding a new entry)

+1 for 2.b that feels like a concurrency and inconsistency nightmare. Having transient pages not conforming to the naming strategy does not feel right.

+1 for 2 since it delays the actual save to the moment where the user already did at least one relevant input.

-1, sounds complex for little benefit. For instance in the context of dealing with user sessions, clustering and so on.

3

I just noticed that option 2 might be an issue if we later want to support AWM templates: we would either need to apply default values client side, before creation (which means either no displayers, or changes to livedata’s API in order to temporarily rely on the template document to render the displayers), or creating the document earlier but only in the case we have a template to apply.

There might be other alternatives I’m not seeing yet, however.