Procedure Request_Save
| Call: | Send Request_Save |
Request_Save performs a save operation by sending Request_Save to the object's DataDictionary object (DDO) Server. If the DDO has nothing to save, it just returns, possibly clearing the appropriate data entry objects (DEOs). An optional save verification confirmation message may be presented. This message is only sent if the there is something to save and the DEO's Verify_Save_msg is set. This operation is performed using the RequestSaveExec message as described below.
Note that this performs a DD Request_Save operation. Saves propagate up the DDO structure.
If the save is successful (or there was nothing to save) the part of the view involved in the save will either be updated or cleared. This is determined by the value of the pbClearAfterSave property. If errors occur during the save, they will be displayed on the browser client.
DEOs may explicitly set their DDO Server by placing a 'Set Server' line directly within the object. More often, DEO objects set their server implicitly by acquiring its server from an ancestor object via delegation. This way a group of DEOs can all share the same server. This is the recommended approach. When a server is not explicitly set, the Request_Save message is delegated to the parent. This process is repeated until the DEO with the explicit server is found. Often this will be the view object itself. This means that all similar Request_Save operations are handled by a single method in the view, making augmentation simpler.
When the browser client selects a save, delete, clear or clear-all, the message Request_Save, Request_Delete, Request_Clear or Request_Clear_All is sent to the server. These do a traditional DataFlex style request operation which is validation, verification and then the actual DD operation (Request_Save, Request_Delete, Clear, Clear_All). A verification is required based on the contents of Verify_Save_msg, Verify_Delete_msg and Verify_Data_Loss_msg. If a verification is required, the client needs to get involved to perform the user verification. This means that the operation requires an additional round trip. If the verification is accepted by the user, a message is sent to the server which handles part two of the request. Those part two messages are RequestSaveExec, RequestDeleteExec, RequestClearExec and RequestClearAllExec. These are the messages that attempt to actually perform the requested DD operation. You can think of these as "pre" and "post" messages.
If the verify messages are 0, which means that a user confirmation is not needed, the "pre" message (e.g. Request_Save) will directly send the "post" message (e.g. RequestSaveExec) without requiring an additional trip to the client.
Here is an rough outline of what happens with a Request_Save (after the delegation to the DEO that sets the explicit server).
Request_Save
If no changes return
Validate All
If not Valid return with errors
If Verify_Save_msg, tell client to present the verification and return *
Else Send RequestSaveExec
RequestSaveExec
Validate All **
If not Valid return
Send Request_Save to DDO
If no Error
If pbClearAfterSave is True
Clear the record and appropriate DEOs
* If the user confirms the operation, the client will make another server request which will indirectly send RequestSaveExec
** The validate All will actually be a duplicate of the prior validation, which means it should validate. It is here as a safeguard. If it does not validate something is wrong and the operation is stopped.
If you need to make a save, delete, clear, clear_all request manually (e.g., within a cWebButton) you should use Request_Save, Request_Delete, Request_Clear and Request_Clear_All and not these "exec" messages.
If you are augmenting these requests you need to be careful as they occur in two steps and it is possible that the second step (the exec) may not get called at all. Notice that the "pre" message (e.g., Request_Save) may have actually performed the entire operation (if there is no verify message) or may have merely launched the operation which might be completed during the next server "post" request (e.g. RequestSaveExec).