Unify edit/view pages

[ebruchez]

A number of existing issues are caused by the fact that the edit and view modes show two different pages, and navigating between the two loses state:

• New → Review → Edit → Save: URL remains at /new #2210
• Liferay: orbeon-liferay-language lost between edit/view/edit #1628
• Review page can be closed by user without warning #1505
• Ask users if they want to load the autosaved data when going from View to Edit #2266

We also have a +1 from customer for keeping the state of a custom instance.

What could we do to fix this? Currently, changing mode causes an internal HTTP POST via the tryChangeMode function. We pass form-version and data-format-version. We also pass fr-noscript, fr-language and orbeon-embeddable as needed.

The reason we do a POST is that in effect, the view mode is exactly the same form as the edit mode, but with "static readonly" controls and the instance marked as readonly.

Now say we do not use an internal POST to change mode: what is the alternative? Staying with the same XForms document, and:

• [ ] change the mode internally
  • [ ] this will cause the instance to change between readonly/read-write and vice-versa
  • [ ] allow readonly-appearance to change dynamically (it is only used by the handlers)
• [ ] check permissions before changing mode!
• [ ] update the URL in the browser (history API as we do from new to edit)
• [ ] send to the client a full update for the content of fr-form-group
  • [ ] this must properly deal with JavaScript controls as we do in general with full updates
• [ ] handle browser back/forward on the client by switching the mode as needed
• [ ] P2: consider whether PDF output could also benefit from this change (see #1573)

Can we see any drawback to this besides the implementation effort?

[avernet]

+1 from customer as this creates unnecessary calls to services, in particular for the autocomplete control.

[ebruchez]

There is also the question of data permissions:

• load form in edit
  • data permissions are obtained and stored in state
• change mode to view
• data permissions are not preserved, and instead we use CheckWithoutDataUserPessimistic() (as of 2023-04)

This particular issue can be solved by securely forwarding data permissions between mode changes.