#24: Confirm changes before unloading form
- Contents
Plone should make sure that you can not navigate away from a form where you have made changes without saving.
- Proposed by
- Duncan Booth
- Seconded by
- Geir Bækholt
- Proposal type
- User interface
- State
- completed
Motivation
Many times it happens that a user has written lots of text in a form and forgets to click Save or by accident clicks on a link or moves to another url (perhaps because another application launches a url). It is desirable that in such a situation the browser (Plone) asks the user if you really want to navigate away and lose his editing.
Proposal
On browsers which support it, Plone should warn before allowing the user to navigate away from a page which contains an edited form. Right now, IE and Mozilla 1.7+ support the onBeforeUnload event that is fired before the browser navigates away. The event allows for displaying a form which gives the user the option to continue to navigate away from the page, or to cancel the navigation and return to editing the form.
The idea is to add handling code linked to this event, that checks if the user has edited/modified the form and if no submit is clicked, he is presented a dialog where he can confirm his action. Browsers that do not support the event won't notice this mechanism (graceful degredation).
The handler should ignore the supplementary forms which can appear on a page (such as the search box, or login portlet). In addition it should be able to work cleanly with add-on products such as Epoz and Kupu where additional code may be required to detect edits.
Implementation
The original idea is base on an article Tracking changes to a form by Jake Howlett. A sample implementation with documentation and unit tests exists in the kupu editor.
Deliverables
What code and documentation needs to be produced? In addition to the standard items:
Unit tests
(There isn't any framework for javascript unit tests in Plone, so one will have to be added.)
Localization
The kupu code to be used as a base does not currently handle localization. The simplest way seems to be to add a translated string to plone_javascript_variables.js
Documentation
Consideration for special fields
Plone has a lot of special form fields that use javascript themselves. We need to take special considerations for these. Examples to investigate : Epoz, Kupu, Archetypes widgets (the boolean and the date ones do some js trickery)
- Epoz
- It is probably easiest to get Epoz to add in support for PLIP24 when it is used in a PLIP24-enabled Plone.
- Kupu
- It is proposed to use the existing code from Kupu as a base for the implementation. The main requirement for Kupu therefore is to maintain a compatible API, and to make it possible for Kupu to give precedence to the Plone handler code.
- Calendar widget
- The calendar widget uses a hidden field to send back the value entered, and a set of select fields which are used client-side only. The code must ignore the state of the client-side fields (since they are updated by javascript after the form has loaded) but must not ignore the hidden field.
- Archetypes boolean widget
- As with the calendar, this uses a combination of hidden and visible controls. In this case the visible control has the correct initial setting so it is sufficient to track the state of either the visible or the hidden control, or both. i.e. there should be no issues here.
- Others
- The documented api should give sufficient control for most conceivable forms.