Retaining unsaved data in an editable list

Some screens contain editable tables into which the user can enter more than one row of data. This data is typically saved once the user presses the Save button and the save API is called. By default, if the save API throws an exception, the screen refreshes and the data entered in the editable table is not be retained. This section explains how you can retain the unsaved data even when an API exception occurs.

The following example explains how this feature can be implemented into an order instruction screen. The screen consists of two JSP files customized to enable this functionality:

Order_detail_instructions_anchor.jsp

Order detail instructions anchor sample

The following table explains the callouts.

Callout Description
A Notice that a JSP parameter called getRequestDOM is passed as "Y" to the header JSP (in this case, order_detail_header.jsp). Any unsaved rows are saved in the request object as an XML file. By passing this parameter, the unsaved rows are retrieved from the request object and merged with the API output that is used to load the screen initially. The refreshed screen now contains the newly modified values that the user entered.
B For the merge logic to work properly, the following parameters have to be passed to identify the elements and attribute on which to perform the merge. Please refer to the following table.

These are the parameters to be passed:

Parameter Name Default Value Comments
RootNodeName Order The root node of the output XML that has the newly entered values merged into it.
ChildLoopXMLName OrderLine The XML element that represents the repeating element name in the editable list.
ChildLoopXMLKeyName OrderLineKey The key that uniquely identifies the repeating XML elements. The merging logic uses this key to determine if the data for the specified element has been modified by the user.

The highlighted code indicates the changes that ensure that the data is retained after an API exception:

Sample code highlighting the data that is retained after an API exception #1

Sample code highlighting the data that is retained after an API exception #2

Sample code highlighting the data that is retained after an API exception #3

Sample code highlighting the data that is retained after an API exception #4

Sample code highlighting the data that is retained after an API exception #5

Sample code highlighting the data that is retained after an API exception #6

The following table explains the callouts.

Callout Description
C The /webpages/yfsjspcommon/editable_util_lines.jspf file has been included in the list innerpanel.jsp. This file merges the user-modified values and the original API output.
D JSP code has been added to ensure that the deletion of a row is handled properly.
E Hidden inputs have been added for user operation and number of rows to add.
F A map of the unique keys of the original repeating XML elements has been added.
G The OldValue attribute of each editable field is set to the value of the original API output using the map previously created. This ensures the value modified by the user is posted to the save API.
H A new row is created in the editable table for each repeating XML element that does not contain a unique key attribute. This indicates that the row has not yet been saved in the database and was entered by the user before the API exception occurred.
I To add a row dynamically when the user clicks on the plus icon under the table, the /common/editabletbl.jsp file is included next. Pass "Y" for the ReloadOnaddLine attributes to this JSP. Each time a new row is added, the screen refreshes. Before these code changes, the new rows are added dynamically without refreshing the screen.