Allow end users to click a link in a read-only paging grid to view the details for the row, and make changes to the data.
The changes are immediately persisted to the external system where the data resides. Sorting and paging the grid shows the latest data from the external system.
This design pattern is not recommended for offline interfaces because reflecting immediate changes in an interface based on user interaction requires a connection to the server.
Unlike the previous grid examples, this recipe retrieves the values for the local!employees array from an external system via a web service. It does so by using the bind() function, which associates two rules or functions with a load() local variable: one that gets the data from the external system, and one that updates the data in the external system. When the variable is referenced, the getter rule or function is called and value is populated with the result.
The definition of the relevant getEmployees rule is given below. This supporting rule uses the webservicequery function to call a sample web service created for this recipe which returns the same employee information shown in previous examples.
The corresponding setEmployees rule uses the webservicewrite function. The setEmployees rule is never executed because the bound local variable local!employees is never saved into in this example. Although it isn't called as part of the example, definition of setEmployees is presented here for completeness.
This recipe writes the updated value of a single employee back to the external system by using another bound variable, local!updatedEmployee. The local!updatedEmployee variable is the saveInto target associated with the "Update" button. When the user clicks the button and the variable is saved into, the setter rule or function given as the second parameter to the bind function is executed. The setter rule or function must return a Writer, which is a special type of value that can be used to write data when a SAIL interface saves into a bound variable.
The definition of the relevant setSingleEmployee rule, which uses the webservicewrite function to write data to the external system through a web service call, is as follows:
The corresponding getSingleEmployee reader rule is defined as follows:
To adapt this example to work with your own web service:
Update the getter and setter rules defined in the bind functions in the example to call your web service operations that get and set the objects
Use the configured webservicequery and webservicewrite functions in the examples above as a guide to determine the corresponding parameters to set for your web services. Refer to the a!wsConfig() documentation to determine which values are appropriate for your web service.
Update the expression below to access and display the fields that are relevant for your web service. For instance, if your web service returns a product instead of an employee, you could replace local!employeeToUpdate.department with local!productToUpdate.description, etc.